从npm切换到pnpm小记

见贤思齐

转转的CI系统和开发环境为什么要从npm切换到pnpm呢。因为在使用npm的时候，遇到几个问题。磁盘空间占用过大首次安装速度慢幽灵依赖导致一些报错那pnpm又是怎么解决上面的问题呢？什么是pnpmpnpm是新一代包管理工具，为什么叫pnpm呢，是因为pnpm作者对现有的包管理工具，尤其是npm和yarn的性能特别失望，所以起名叫做performancenpm，即pnpm（高性能npm）我们今天要使用pnpm，那pnpm有哪些优势呢1、npm的问题在npm@3之前，node_modules结构是干净、可预测的，因为node_modules中的每个依赖项都有自己的node_modules文件夹，在package.json中指定了所有依赖项，比如项目a依赖项目b,项目c也依赖项目b，这样如果a和c依赖的b的版本不一致，也不会出问题node_modules└─ a   ├─ index.js   ├─ package.json   └─ node_modules      └─ b         ├─ index.js         └─ package.json   c   ├─ index.js   ├─ package.json   └─ node_modules      └─ b         ├─ index.js         └─ package.json上面结构有两个严重的问题：package中经常创建太深的依赖树，这会导致Windows上的目录路径过长问题当一个package在不同的依赖项中需要时，它会被多次复制粘贴并生成多份文件为了解决上面的问题，npm提出了node_modules扁平化结构，在npm@3+和yarn中，node_modules结构变成：node_modules├─ a|  ├─ index.js|  └─ package.json└─ b|  ├─ index.js|  └─ package.json└─ c   ├─ index.js   └─ package.jsonhoist机制下，b包被提升到了顶层。如果同一个包的多个版本在项目中被依赖时，node_modules结构又是怎么样的？包B1.0被提升到了顶层，这里需要注意的是，多个版本的包只能有一个被提升上来，其余版本的包会嵌套安装到各自的依赖当中，至于哪个版本的包被提升，依赖于包的安装顺序！扁平化之后，又引入了新的问题幽灵依赖，解释起来很简单，即某个包没有在package.json被依赖，但是用户却能够引用到这个包。还有NPMdoppelgangers问题，当包有多个版本，会被重复安装多次。2、pnpm的方案pnpm使用的是npmversion2.x类似的树形结构，同时使用.pnpm以平铺的形式储存着所有的包。我们称.pnmp为虚拟存储目录，该目录通过 @来实现相同模块不同版本之间隔离和复用，由于它只会根据项目中的依赖生成，并不存在提升，所以它不会存在之前提到的Phantomdependencies问题！然后使用Store+Links和文件资源进行关联。简单说pnpm会把包下载到一个公共目录，如果某个依赖在sotre目录中存在了话，那么就会直接从store目录里面去hard-link，避免了二次安装带来的时间消耗，如果依赖在store目录里面不存在的话，就会去下载一次。通过Store+hardlink的方式，不仅解决了项目中的NPMdoppelgangers问题，项目之间也不存在该问题，从而完美解决了npm3+和yarn中的包重复问题！3、workspacepnpm除了安装速度快，节省磁盘空间，避免幽灵依赖等优化，也内置了对monorepo的支持。使用起来比较简单，在项目根目录中新建pnpm-workspace.yaml文件，并声明对应的工作区就好。packages:  # 所有在 packages/ 子目录下的 package  - 'packages/**'切换到pnpm转转的CI系统。一共有6台机器，是前后端公用的。之前使用npm存在几个问题。第一个就是安装速度慢，导致编译时间过长。第二个是node_modules过大。导致每天必须清除一下机器上node_modules，不然就会出现磁盘空间不足的问题。切换成pnpm之后，我们测试的结果，单台机器最少能节省了30G的空间，安装速度提升一倍以上。因为直接从npm切换到pnpm，大多数的项目都会存在幽灵依赖的问题。导致项目报错。我们的切换方案是在项目设置中勾选是否使用pnpm。默认是npm。单个项目在本地切换之后，在CI平台上设置成pnpm就完成了升级。切换pnpm的一些问题使用pnpminstall--shamefully-hoist如果依赖一直有问题，可以使用pnpminstall--shamefully-hoist创建一个扁平node_modules目录结构,类似于npm或yarn解决幽灵依赖时，安装默认的包导致报错先使用npm安装，生成package-lock.json,安装缺少的包时，使用lock里面的版本即使删除了node_modules和lock文件，安装时，特定的包还是报错比如我们在升级时，一个包把最新的版本删除了。导致安装时一直失败。可以尝试使用pnpmstoreprune来删除