北京
一个共享包只导出 .ts 源文件，消费方写下一行 import { util } from "@scope/shared/util"。类型检查通过了，打包时却报错——路径到底指向 util.ts、util/index.ts 还是 util.js，没人说得清。
这类失败在 monorepo 里反复出现，根源是一个错位：TypeScript 禁止源码里出现 .ts 扩展名，而运行时的模块解析往往又需要它。团队于是绕路——写路径映射、加构建期重写步骤，或者干脆放弃显式扩展名。结果是配置越堆越脆，一个 tsconfig.json 写错，跨包导入就悄悄断掉，直到打包那一刻才暴露。
这个开关只做一件事
TypeScript 6.0 的 --allowImportingTsExtensions 针对的就是这个错位。开启后，源码里可以写 import { fn } from "./utils.ts"，不再触发 TS1479 错误。编译器不再强制那条老规则——非声明文件的导入说明符必须省略扩展名。
需要说清楚的是它不做什么：这个标志不重写导入，也不产出 JavaScript。它只是移除编译期的禁止。真正的路径解析交给下游工具——打包器、加载器，或者带自定义解析钩子的 Node.js。
这条界线很关键。它解锁的是书写上的便利，至于这些导入能不能跑起来，取决于运行时环境。
monorepo 里立刻能拿到的两个好处
第一，TypeScript 原生的构建工具不再需要路径重写插件。第二，解析失败会更早暴露——编译器不再用一条笼统的扩展名规则把错误路径盖住。失败模式从“生产构建时打包器静默报错”变成“类型检查阶段立刻反馈”。
为什么现在可行？因为 Vite、esbuild、Turbopack 这类现代打包器已经能原生解析 .ts 路径。而 monorepo 的包边界，常常需要显式扩展名来避开 Node.js 解析的歧义。
怎么开，以及两个坑
标志写在 compilerOptions 里，但有一个前置依赖：moduleResolution 必须设为 bundler 或 nodenext。编译器会强制这条约束，因为该标志面向的是由打包器或现代加载器直接处理 TypeScript 文件的工作流。如果配成 moduleResolution: "node"，会触发配置错误 TS5110。
典型配置里，noEmit: true 常和它一起出现。原因还是那句话：标志不会在产出阶段重写导入说明符。如果 TypeScript 产出的 JavaScript 里留着 import "./utils.ts"，Node.js 执行就会失败，除非有运行时加载器把 .ts 翻译成 .js。所以 monorepo 里用这个标志的团队，通常把产物生成整个交给打包器，noEmit 也就顺理成章。
两个边界情况值得留意。其一，如果项目用 "module": "esnext" 或 "module": "nodenext"，编译器会要求所有导入说明符在运行时合法——标志只在类型检查阶段放行 .ts 扩展名，剩下的得靠打包器兜住。其二，开启这个标志会让 Node.js 原生执行失效，除非配自定义加载器；它适合打包器驱动的工作流，或者在 ESM 钩子下配合 tsx、ts-node 使用。
还有一个容易混淆的近亲：--rewriteRelativeImportExtensions 会在产出阶段把 .ts 改写成 .js，因此需要 --noEmit 或纯打包器工作流；而 --allowImportingTsExtensions 不修改输出。两者解决的是不同阶段的问题，别把它们当成同一个开关。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
