CC @weswigham

是的，我们肯定希望解决这个问题；不幸的是，构建模式的操作方式并不适合轻松地实现这个功能，而不需要完全执行构建模式原本打算避免的操作——解析每个文件中的(非相对)指定符并解决它们。从程序缓存中提取现有数据的逻辑对于非初始构建来说可能是一个有价值的优化，即使我们能找到一种方法来获取初始构建的列表。

但是这似乎是一种不太一致的经验。
如果我真的做了

tsc -b

some change to package.json

tsc -b => // This does not detect change..  and completes as is.. At which point only way to observe change is to do clean compile or delete tsbuildinfo. 
// If we are relying here on change to source file or some such to observe the change why not in watch..

行为与

tsc -b -w which detects the change and does the build.

文件监视器通常进行轮询，因此它们与它们相关联的成本更高。
如果这是情况的话，只更改package.json和目录更新(例如npm install替换文件)的概率是多少？可能目录监视器更好，这就是我们用于失败查找的方式。
话虽如此，我强烈认为，ts构建应该监视那些可以通过配置文件或一些可以观察到的启发式文件来推导出来的东西，无论是否创建程序。

文件监视器通常采用轮询方式，因此它们与它们相关的成本更高。
如果是这样，仅更改package.json文件与目录更新(如npm install替换文件)的概率是多少？可能目录监视器更好，这就是我们用于失败查找的方式。
所以在单仓库设置(如果我没记错的话，这是构建模式的主要用例)中，只有包文件发生变化而不改变整个目录结构是非常常见的(我想这和人们重构他们的文件结构或包一样常见)。包文件本质上是简化的源文件——它们实际上有导入，人们可以根据自己的喜好随意更改它们(随着现代包文件功能的增加，这种更改的频率也在不断增加)。除此之外，大多数node_modules文件夹通常只安装一次并完成，很少更新。
难道我们不应该尽可能地使用目录监视器吗？我想如果主机支持的话，我们在最根位置的一个单独的目录监视器是我们已经尝试过的方法，然后对其进行过滤。不过我不太熟悉各种文件监视策略的性能特性。
话虽如此，我坚信ts构建应该监视那些可以通过配置文件或一些可以观察到的启发式文件得出的东西。
我认为在递归目录结构中监视所有可能的包文件路径肯定是一个选项(我想使用目录监视器会很容易且便宜)。当然，在没有程序数据的情况下可以推导出来，然后在程序创建过程中实际使用的包可以在监视模式下将相关位置缩小到更小的范围。