npm、yarn、pnpm —— 再谈幽灵依赖

本文介绍: 之前我们讲过，“幽灵依赖” 就是：未在项目package.json中声明的依赖，但在项目中依然可以意外的被正确引用。

banner

之前我们讲过，“幽灵依赖” 就是：未在项目 package.json 中声明的依赖，但在项目中依然可以意外的被正确引用。

原因就是 npm v5 只后，把所有的依赖全部拍平整理到项目的 node_modules 之中，才导致了上面说的这种情况。（yarn 也一样，都存在幽灵依赖）

npm install

看之前文章的图片。我们可以看到，在 express 的 package.json 中，他声明的依赖项并不是项目的依赖项，但也被拍平到 node_modules 文件夹中。所以有时候我们可能会不小心引用到这个依赖，开发者会误判，以为是项目自己的依赖，导致某些玄学的报错。

归功于最重要的一点，pnpm 是通过自动硬链接 (hard link) 和软链接 (sybolic link) 来实现 npm 模块的管理。

还是以 express 举例，在 node_modules 根目录只有一个 express，并不像 npm 那样，把所有依赖都扁平化管理，而是通过软链的形式链接到 .pnpm 内部，再去详细管理依赖的版本。在 .pnpm 内部也是平铺的，但是是允许不同版本的依赖平铺在一个层级，同时对于 express 诸多依赖，也是直接软链到平铺的模块中。

通过对工作区内部的分析，可以看出都是通过软链接实现的，那硬链接是如何发挥作用的，现在我们来继续来看 .pnpm 目录，这个目录的一级文件，都是通过直接的硬链接，链接到全局的存储空间，从而可以实现多个项目共用一份依赖。

显示所有内容

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。