给大代码库的类型检查提提速

[GiantHard]

每次提交代码执行类型检查太慢了，要怎么提速呢？—— 给大代码库的类型检查提速

太长不看（ By GPT4 ）：本文讨论了如何提高大型 TypeScript 代码库的类型检查速度。作者提出利用 TypeScript 的增量构建模式来优化性能，并提供了一种方法来维护项目之间的'references'字段。实证结果显示这种方法可以显著减少类型检查的耗时，从而提高开发效率。

[GiantHard]

如果各位有兴趣的话，也欢迎在评论区分享你的项目中执行类型检查的方案。

[MinonHeart]

1. 文中提到的时间，真的不算长
2. commit hook 中执行类型检查，时间确实长了，不合理。我们的做法是放到 ci 中，本地不做构建时类型检查，由编辑器提供
3. TPR 中不同项目导出同名类型会导致类型错误，不知道这个你是怎么解决的？
4. 另外，Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

[GiantHard]

@MinonHeart #2

> TPR 中不同项目导出同名类型会导致类型错误

没法复现你说的这个问题，

讲道理不同模块下出现同名类型的情况很常见，只要同一模块下的类型名称不重复即可

> Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

确实这俩都支持增量构建，但是 nx 的适用性更加广泛。我自己的使用中，tsc 负责把代码编译成 d.ts ，nx 负责缓存各种构建产物（ tsc, vite, webpack, svgr 等等），所以从定位上，nx 是个构建工具，而 TPR 只是用来给 tsc 加速而已，类似的，vite, webpack 之类的也有构建缓存功能，但是使用这些工具跟 nx 并不冲突。

最后，往一个项目中引用的工具越多，项目都会变得越复杂，比如很多人吐槽的新建一个前端项目模板，页面代码没几行，净是 .xxxrc 。我觉得这类问题目前看来是无解的，这是为了提高开发体验做的牺牲。不过，我觉得引入 nx 能够缓解手动维护这些配置文件的繁琐，靠官方、社区维护的插件，已经能够在创建项目、升级依赖的过程中简化很多操作了。

[MinonHeart]

> TPR 中不同项目导出同名类型会导致类型错误

可能是和第三方库的类型冲突，也可能是我们自定义的全局类型冲突，刚出时候做的调研，具体记不清了。

> Nx 管理工具和 TPR 感觉功能重叠了，同时使用导致项目结果太复杂了

两边都是通过 cache 提速的，另外 TPR 的项目依赖需要手动编写（ tsconfig.json ），和 package.deps 重复了，维护不会很麻烦吗？（有看过一些同步的工具，但是还是挺麻烦的）

----
额外想到几个问题：

1. js 和 ts 混合项目，TPR 怎么处理？

调研时候，是在 js 项目中增加一个 ts 入口文件，暴力但确实能用。

2. TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

当时想到的是：

2.1 Copy 到 dist 目录，但是这样 TPR cache 对二进制资源也就不生效了（理论，没有实践过）

2.2 生成的 js 、dts 和 ts 在同一层级，这样不方便管理

3. TPR 在 watch 和 build 上有很大的优势吗？

没有实践过

[GiantHard]

@MinonHeart #4

> 两边都是通过 cache 提速的，另外 TPR 的项目依赖需要手动编写（ tsconfig.json ），和 package.deps 重复了，维护不会很麻烦吗？（有看过一些同步的工具，但是还是挺麻烦的）

在我的项目中，维护 tsconfig.json 的 reference 用的是自己开发的工具 https://github.com/ZeekoZhu/js-prelude/blob/main/packages/ts-sync-ref/README.md ，把这个包装成 nx executor 后，就方便很多了。

> js 和 ts 混合项目，TPR 怎么处理？

TPR 只是用来加速 tsc 而已，tsc 查找类型定义的方式可以通过给 tsc -b/-p 命令加上 --traceResolution 来 debug 。你的这种做法看起来也没啥问题。另一种做法是通过 package.types 字段指定 .d.ts 文件。

> TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

我把 tsc 当作 type checker 用的，生成 js （包括 copy assets ）用的是 vite ，跟 tsc 没有任何关系。另外，build mode 提升构建速度的方式是复用类型定义，也跟二进制文件没有关系。

> TPR 在 watch 和 build 上有很大的优势吗？

这里我引用一下 TypeScript 的文档：

> By separating into multiple projects, you can greatly improve the speed of typechecking and compiling, reduce memory usage when using an editor, and improve enforcement of the logical groupings of your program.

如文档所述，启用 Project Reference 后，tsc 跟 tsserver(language server) 都会变得更加高效。我实际测试下来，类型检查速度能提速不少；编辑器的话，我平常用 WebStorm ，这个 IDE 根本不用 lsp ，所以没有感觉到内存占用的减少。

[MinonHeart]

@GiantHard #5

> js 和 ts 混合项目，TPR 怎么处理？

最初可能想偏了，想用 TPR 来担任 js 、ts 的编译和 cache 。只用于 tsc 加速确实没什么问题

> TPR 项目中有引用图片/SVG 等这些二进制资源怎么处理？

这和上个问题有关联，按你的描述我们的用法不一样

> TPR 在 watch 和 build 上有很大的优势吗？

按我们的项目来说，类型检查占用总构建时间的比例约为 1/3 ，本地跑不划算，不清楚 TPR 能节省多少时间。官方这点说的没错，但是没看到很明确的数据。构建工具也是使用 cache 来提升构建速度，如果去除类型检查（让 CI 来做），理论上构建速度是相近的，因此后续也没有做这方面的调研了。