配置noEmit的TypeScript项目使用项目引用能否实现性能提速？

首先纠正认知偏差 #

你此前了解到的「项目引用机制要求必须输出.js和.d.ts」是存在误导的——这个要求是官方文档针对构建场景的最佳实践说明，而非技术上的强制约束。项目引用的核心能力是帮TypeScript拆分解析边界、实现增量检查，这套逻辑完全可以和noEmit配置共存，不会因为关闭文件输出就丧失对应的性能收益。

实际落地后的效果参考 #

VS Code（依托tsserver）的交互响应速度 #

• 只要按照项目边界正确配置references引用关系，哪怕全量开启noEmit，tsserver也会按拆分的项目边界隔离模块缓存，不会把所有跨模块代码拉到同一个全局作用域做全量解析
• 这种隔离能大幅缩小实时报错、代码补全、跳转定义时的解析范围，常规规模的跨端/全栈项目落地后，编辑器首次加载、编辑时的卡顿感会有非常直观的改善，响应速度提升通常在40%以上

tsc --noEmit的检查速度 #

• 配合项目引用的增量检查逻辑，tsc会自动跳过未发生代码变更的子项目的重复类型扫描，不需要像之前那样每次都做全库遍历
• 落地时只要注意不要把所有子项目的src目录直接塞进根tsconfig的include范围，严格通过references声明依赖链路，哪怕全程不输出任何文件，全量检查的耗时也能比单体配置缩短60%以上

noEmit场景的落地可行性 #

• 业内已经有大量同配置的实践案例：很多团队为了避免项目引用生成的文件污染源码目录，会直接在所有tsconfig里开启noEmit，同时配合composite: true启用项目引用能力，最终拿到的性能收益和开启完整文件输出的场景几乎没有差别
• 甚至有团队把outDir指向系统临时目录，完全把项目引用的输出当纯缓存用，既不影响日常构建流程，又能拿到加速效果

适配你现有目录结构的最小可落地方案 #

不需要改动现有目录结构，只需要补充少量配置即可：

• 三个子项目（common/client/server）的tsconfig补充两个字段：

  {
    "compilerOptions": {
      "composite": true,
      "noEmit": true,
      // 你原有的所有编译配置保持不变
    },
    "include": ["src/**/*", "test/**/*"]
  }
  

• 根目录新增tsconfig.json，不配置任何编译选项，只声明所有子项目的引用关系：

  {
    "files": [],
    "references": [
      { "path": "./common" },
      { "path": "./client" },
      { "path": "./server" }
    ]
  }
  

• 原有的pre-push钩子检查命令，直接替换为tsc --build即可——因为每个子项目已经开启noEmit，执行过程不会生成任何多余的js/声明文件，同时能自动触发增量检查逻辑，大幅缩短检查耗时

内容的提问来源于stack exchange，提问作者danvk