Nest.js是一个流行的node服务端框架，最近发现它有一个很大的PR。本次PR涉及50多个文件，800多行代码改动：同学们肯定会认为这么多代码改动一定是大版本升级。但是并没有更新版本号：可以看到Nest从gulp编译切换到了tsc编译，但是版本号还是9.1.2。为什么这么大的PR版本号不改？看看PR的内容：这个PR从gulp切换到tsc的ProjectReference，优化了编译性能，启动更简单。只是构建相关的优化，不更新版本号也很正常。可能有同学会问，什么是ProjectReference？为什么能提高tsc编译性能？我们先看看Nest是如何编译nest源码的：通过gulp的build命令，将产品输出到node_modules/@nestjs。gulp记录下项目中每个包的tsconfig.json：然后用tsc读取每个tsconfig.json编译ts代码：这个过程很容易理解，就是通过tsc根据每个tsconfig.json编译ts代码，并输出到不同的目录，gulp只是组织了这个过程。那么现在tsc是怎么编译的呢？首先，现在不用gulp组织流程了，直接执行tsc就可以了，加-b就可以了，这个是用来开启项目引用的：所谓项目引用就是这个东西：image.png就是要通过tsconfig中的引用引用其他项目。如果其他项目也依赖于其他项目，可以再次引用：编译的时候会一起编译。这和单独运行tsc不一样吗？有区别吗？差别很大。现在执行tsc-b后，每个项目下都会生成这样一个tsconfig.build.tsbuildinfo文件：每个项目都有：那么这个文件有什么用呢？看一下内容：记录了本项目所有编译的文件名：和hash的版本号，是否访问全局作用域：再编译的时候有没有区别？肯定是编译完了，就不用再编译了。相当于做了一层缓存。每次比较变化文件的hash，只有有变化，才会编译。不同的项目分别缓存。如果一个项目发生变化，只需要单独编译那个项目，其他的可以跳过。这自然会提高编译性能。不过只是提高了二次编译的性能，第一次编译还是需要全编译。这就是为什么在PR中提到更快的重建：我们知道为什么我们从gulp切换到tsc项目参考。新版nest如何调试？我们可以直接使用nest工程自带的案例调试。Nest提供了一个示例目录，下面有很多示例项目：我们新建一个.vscode/launch.josn调试配置文件：image.png添加这个调试配置：{"name":"LaunchviaNPM","request"：“启动”，“runtimeArgs”：[“运行脚本”，“开始”]，“runtimeExecutable”：“npm”，“控制台”：“integratedTerminal”，“cwd”：“${workspaceFolder}/sample/01-cats-app/","skipFiles":["
