transpileOnly 时超慢的 ts-loader 时间：false？

问题描述

我正在尝试诊断一些缓慢的构建速度。以下是我认为相关的一些数量。我想知道是否有可能的解释和优化来加速这些而不会对开发人员做出太多妥协。它是一个 pnpm hoist=false monorepo，在依赖关系中有多个 typescript v4 项目。一个最重要的项目是 webpacked，因为我想要处理和捆绑作为库的字体、图像和样式资产。

tsc --build

Types:                80
Instantiations:        0
Memory used:    1324253K
I/O read:          1.71s
I/O write:         0.00s
Parse time:       17.67s
Bind time:         2.93s
Check time:        0.00s
Emit time:         0.00s
Total time:       20.60s

Found 428 errors.

带有 projectReferences: true,onlyCompileBundledFiles: true,declarations: false,transpileOnly: true 的 webpack 4 和 ts-loader v8.0.14

~142 秒，22MB 内存上限（根据 Windows 任务管理器），但当然没有发现错误。

带有 transpileOnly: true、sourceMap: false 且没有 devtool 的 webpack 和 ts-loader。

在 3.67 小时内完成！内存占用高

带有 transpileOnly: false 的 webpack 和 ts-loader

~2 小时，26 GIGS 内存上限（使用 NODE_OPTIONS=--max_old_space_size=32768），发现 428 个错误。

源.tsx 少于 3000 个？文件，但似乎还有 5000 多个 .d.ts 文件从 node_modules 处理（即使 skipLibCheck: true）。由于它最终确实准确地完成了，它正在做一些事情并取得进展。我认为众所周知，webpack sourcemaps 可以让你罚款 60%，但我不认为这就是这里发生的全部。

显然有很多细节和设置我没有提到，但也许你发现了一个我应该检查的秘密？与常规 tsc 构建或 ts-loader transpileOnly 构建相比，您是否发现 ts-loader 在类型检查时有巨大的损失？我可以使用任何高级诊断技术来破解这个问题吗？

解决方法

您可以尝试将解析器的排除字段设置为排除 node_modules 文件夹和 .d.ts 文件。

另请查看 ts-loader 的 projectReferences 参数和 experimentalFileCaching 参数。

我目前没有足够的声誉发表评论；抱歉，我将此作为答案发布！出于好奇，在这个项目上运行打字稿编译器的速度有多快？我想知道除了那些专门针对 ts-loader 的配置（例如源映射模式）之外，缓慢是否与 webpack 配置有关。