建议

🔍 搜索词

idle watch watcher cpu chokidar

✅ 可实现性检查清单

我的建议满足以下准则：

• 这不会对现有的TypeScript/JavaScript代码造成破坏性的改变
• 这不会改变现有JavaScript代码的运行时行为
• 这可以在不根据表达式的类型发出不同的JS的情况下实现
• 这不是一个运行时特性(例如库功能、非ECMAScript语法与JavaScript输出、新的JS语法糖等)
• 这个特性将与 TypeScript's Design Goals 的其他部分保持一致。
• 实际上会进一步推进目标10,跨平台开发*

⭐ 建议

请添加以下一项或多项：

• 将chokidar作为tsconfig::watchOptions.watchFile和tsconfig::watchOptions.watchDirectory的新选项
• 将chokidar作为env::TSC_WATCHFILE和env::TSC_WATCHDIRECTORY的新选项
• 将chokidar设置为默认的观察者——也许取决于项目中是否可用chokidar

💻 用例

在使用create-react-app时，我注意到我的机器往往会变得相当响亮。调查后，我发现原因出奇的高CPU利用率。这反过来，我可以追溯到这个问题：
TypeStrong/fork-ts-checker-webpack-plugin#236
那里的解决方案是将TSC切换到fs.watch而不是fs.watchFile。这在很大程度上有效。然而，正如@sheetalkamat在#31048(评论)中指出的那样，这种实现方法已知存在问题。这就是为什么它不是默认选项，而且在可预见的未来不会成为默认选项。

之前的讨论

#31048 讨论了这个请求的背景。在那里，@nicoburns已经提出了这个问题：
你是否考虑过切换到Chokidar?它是在Node生态系统中广泛使用的经过实战考验的解决方案。我们在工作中正在转向TypeScript,而我的2015 MacBook Pro上的watch进程每个占用约45%的CPU。据我所知，Node的内置文件监视功能通常被认为是有问题的，不适合生产使用。
作为回应，@jasonwilliams指出webpack已经切换回了fs.watch,这可能表明它现在已经修复了。不幸的是，node v16仍然有相同的警告，而webpack的切换似乎没有我们希望进行的那么彻底： webpack/watchpack#130
#19762 和 #17506 也显示了性能问题。 #19762 实际上与 TypeStrong/fork-ts-checker-webpack-plugin#236 具有相同的分辨率，而 #17506 似乎引发了一些密集工作。