现象：重新install失败
打包平台执行命令：npm run reinstall
{
"bootstrap": "pnpm install",
"reinstall": "rimraf pnpm-lock.yaml && rimraf package.lock.json && rimraf node_modules && npm run bootstrap"
}
产生报错：
原因探索：pnpm依赖的依赖，版本更新造成了问题
自动化编译平台的日志，对比历史编译记录，发现esbuild的版本号变了，但是我们自己项目里的package.json没有引用过esbuild。
观察lock文件和源码，发现是esno@0.14.1引用了esbuild：
这样在重新install的时候，esbuild更新到当时最新的0.27.1版本，导致了报错。
处理方法探索：
为什么不能使用 patch 修改依赖源码
相关文章：如何优雅地修改node_modules里依赖的源码？
我们想当然地认为，使用 pnpm patch去修改源码，把 "esbuild": ">=0.13.0"改成锁定版本的"esbuild": "0.14.27"就能解决问题，实际上这种场景不适用pnpm patch。
用pnpm patch，修改源码时，不会等esno安装好再去安装esbuild，下图是没有pnpm-lock.yaml文件的时候使用patch命令报的错。
No pnpm-lock.yaml found: Cannot patch without a lockfile
用pnpm patch只能去修改源码，在项目运行阶段生效，而package.json文件并不算源码，我们希望在install阶段处理。
peerDependencies，描述项目对某些依赖的共存期望
我在esbuild-register中也发现了esbuild，dependencies和peerDependencies都有，但实际安装的依赖里，并没有esbuild@0.14.8。
peerDependencies的主要作用是表示项目需要一个特定版本的依赖项，但并不主动去安装它，而是将安装这个依赖的责任交给最终的使用者。
因此，如果esno里也定义peerDependencies，我们就能在自己的主项目中定义esbuild的版本号并锁定了。
上面两种方案，都可以通过重新推送npm包的方式解决。相关文章：手把手教你如何配置私有npm库。处理方式：fork一下esno，并改个名字，然后修改package.json，无论是修改esbuild的版本号，还是添加peerDependencies，都可以解决我们的问题。修改完成之后，上传到公司的私有库上即可使用。
更简单的方案：overrides，强制重写依赖
"pnpm": {
"overrides": {
"esbuild": "0.14.27"
}
}
设置后，所有标记为该版本可用的依赖，都会使用我们指定的这个版本。
优化打包平台
直接检测 pnpm-lock.yaml有没有更新，如果有，就reinstall(pnpm-lock.yaml不删)。
{
"reinstall": "rimraf node_modules && npm run bootstrap",
}
如果pnpm-lock.yaml文件有改动，就删除node_modules目录重新install。原来的reinstall是删掉了pnpm-lock.yaml的，导致install的时候都按照package.json把版本都升级了，导致意外的问题。
Jenkins配置：代码提交时如果有pnpm-lock.yaml，就执行reinstall命令，根据提交的pnpm-lock.yaml文件取安装依赖。
git diff --name-only $GIT_PREVIOUS_COMMIT $GIT_COMMIT | grep pnpm-lock.yaml && npm run reinstall
npm run build
其他问题处理：在一个项目里同时引用两个不同版本的依赖
设置别名：
"dependencies": {
"echarts": "^4.8.0",
"echarts-latest": "npm:echarts@^6.0.0"
}
总结
npm 官方文档明确建议：“always commit your package-lock.json”。yarn 和 pnpm 同样要求提交各自的锁文件（yarn.lock、pnpm-lock.yaml），这个对团队协作保持环境统一有重要意义。非必要情况下，我们尽量不会自动更新依赖的版本并且直接打包部署，避免出现意外的问题。
