如下图所示，A 的依赖项C 被提升到了顶层，如果后续有安装包，也依赖C，会去上一级的node_modules查找，如果有相同版本的包，则不会再去重复下载，直接从上一层拿到需要的依赖包C 说明：为什么自己的...为什么说是一定程度上？ 因为如上图所示，B 依赖的C v2.0.0，并没有提升，依然是嵌套依赖。...因为在两个依赖包 C 的版本号不一致，只能保证一个在顶层，上图所示C v1.0.0 被提升了，v2.0.0 没有被提升，后续v2.0.0 还是会被重复下载，所以当出现多重依赖时，依然会出现重复安装的问题...与此同时，我们把C，提升到了顶层，即使项目package.json，没有声明过C，但是也可以在项目中引用到C,这就是幽灵依赖问题。...我理解的是window下也是可以使用的，pnpm 已经帮我们做了兼容，只是没有使用软链接的方案。 pnpm 常见问题 为什么使用硬链接？ 为什么不直接创建到全局存储的软链接？
但是，在锁定包版本之后，如果需要在项目中更新某些包，则需要手动更新明确的包版本。...但是，使用符号链接也可能导致某些不兼容问题，因为符号链接可能会在不同操作系统、文件系统或设备中处理不同。...Q: 为什么说 pnpm 这种 基于内容寻址 的方式对磁盘空间利用效率比较高 ? A: 1. 不会重复安装同一个包。...针对 npm2 的两个缺点，npm3 做了更新， 不再使用嵌套的结构，而是将依赖进行展平， 这样就能解决层级依赖深和包的利用率的问题，那么上面的依赖关系就会变成下面这个样子： 在文件里看就是下面的这个样子...一旦所有包都硬链接到 node_modules，就会创建符号链接来构建嵌套的依赖关系图结构。
为什么会出现pnpm？因为yarn的出现并没有满足作者的一些期待，反而有些失望。...扁平化的依赖树带来了一系列问题(具体后面会讲) 为什么叫pnpm？...Virtual store 虚拟存储，指向存储的链接的目录，所有直接和间接依赖项都链接到此目录中，项目当中的.pnpm目录 如果是 npm 或 yarn，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次...，项目中则通过symbolic link链接到.pnpm/node_modules目录中，依赖放置在同一级别避免了循环的软链。...在根目录中运行prepare生命周期。 在根目录中运行prepublishOnly生命周期。 在根目录运行prepack生命周期。 对于每个更改的包，按照拓扑顺序(所有依赖项在依赖关系之前): i.
如今 npm 已经存在 12 年了，为什么还有其他替代品？...它和 Yarn 一样，是为了解决某些 npm 痛点的。...这是通过 node_modules 层实现的，使用符号链接创建一个嵌套的依赖关系结构，其中文件夹中的每个包都是到存储的硬链接。 这是为什么 pnpm 会在快速和磁盘效率上有大幅提升的原因。...安装包时，它们的文件将从该位置硬链接，不消耗额外的磁盘空间。这允许您在项目之间共享相同版本的依赖项。 由于这种依赖关系的链接，它也比它的替代品快 2 倍。...外面的 可以看到 react 是一个符号链接指向了它的真实位置 react 包的真实位置在 /node_modules/.pnpm/react@17.0.2/node_modules/react 所有你安装的依赖都存在
虽然可以通过npm config set save-exact true命令关闭在版本号前面使用^的默认行为，但这个只会影响顶级依赖关系。...即便npm现在也能阻止用户多次重复发布库的同一版本，但是npm管理员仍然具有强制更新某些库的权力。...pnpm 正如我所提到的，在pnpm的作者Zoltan Kochan发表了“为什么要用pnpm？”之后，我才知道pnpm。...我不会介绍太多的细节（因为这篇文章已经发布很久了）, 但是我想指出的是，pnpm运行起来非常的快，甚至超过了npm和yarn。 为什么这么快呢？...正如Sebastian在Twitter上指出的那样，他最初是打算在yarn中使用符号链接的，但是由于其他一些原因放弃了它。
当然有，这不是 pnpm 就出来了嘛。 那 pnpm 是怎么解决这俩问题的呢？ pnpm 回想下 npm3 和 yarn 为什么要做 node_modules 扁平化？...展开 .pnpm 看一下： 所有的依赖都在这里铺平了，都是从全局 store 硬连接过来的，然后包和包之间的依赖关系是通过软链接组织的。...比如 .pnpm 下的 expresss，这些都是软链接， 也就是说，所有的依赖都是从全局 store 硬连接到了 node_modules/.pnpm 下，然后之间通过软链接来相互依赖。...官方给了一张原理图，配合着看一下就明白了： 这就是 pnpm 的实现原理。 那么回过头来看一下，pnpm 为什么优秀呢？...pnpm 则是用了另一种方式，不再是复制了，而是都从全局 store 硬连接到 node_modules/.pnpm，然后之间通过软链接来组织依赖关系。
早期npm （~2015年） 早期的npm其实依赖关系十分简单，可以直接体现在node_modules的目录结构中。...pnpm的出现（2017-06） 17年中，出现了一个新的与众不同的包管理器pnpm。 pnpm 拒绝了使用与npmv3一样的去重和提升机制，而是使用符号链接。...所以从目前来看，pnpm的符号链接我认为似乎是最合理的方式，通过一个引用符号，指向具体的依赖包，那么为什么npm v3或者yarn当时没有选择采用这样的方式呢？ 难道因为windows的路径字符限制？...然后我去看了 pnpm关于windows上node_modules的处理方式，官方有个qa 大概是说他们说可以在windows上运行，在windows上使用符号链接多多少少有点问题，但是pnpm用 junctions...关于硬链接，微软有关于这个的解释，先贴张图，我没来得及仔细看，大概就是一种映射关系吧，感兴趣的朋友可以详细了解一下，结论可以在评论区交流一下 yarn PnP（Plug'n'Play）（2018-09
此外 @grpc/grpc-js 的上层依赖在管理包的时候，使用 ^ 来指定版本导致只会锁住包的 major version。 1.5 为什么没有使用 lock 文件？...，如果不采取某些方式来管理，维护性也会变得很差。...由于项目的工程化换为了 pnpm，那么在各个微服务自身根目录的 node_modules 会存在指向根目录 node_modules 的软硬链接，并且对于 Monorepo 其他模块的引用，也是使用软链接的方式进行引用的...3.6 软链接与硬链接 软链接和硬链接在 pnpm 的底层原理中使用很广泛，那软链接和硬链接的区别是什么？又启发了我们用于项目优化的什么地方呢？...我在项目入口的设置用到了这个特性。可以看下面这个图： 软链接是相当于源文件的一个快捷方式，所以在执行逻辑时还是按照原有文件位置进行依赖查找，这样能够不影响被软链后的文件执行逻辑。
该文件记录了实际安装的软件包和版本信息，以及确切的依赖关系树，可用于确保在后续安装过程中保持一致的依赖项状态(npm ci)； PS: 本文仅以 NPM 举例，yarn、pnpm 的执行算法虽差异较大，...这就引入 NPM@3 的优化策略：扁平化依赖结构，也就是将所有的模块 —— 无论是顶层依赖还是子依赖，都会直接写入到在项目顶层的 node_modules 目录中，例如： 依赖结构： - A - B...这种不明确的依赖关系是非常不稳定的，可能触发很多问题： 不一致性：幽灵依赖可能导致应用程序的行为在不同的环境中表现不一致，因为不同环境中可能缺少或包含不同版本的幽灵依赖； 不可预测性：本质上，幽灵依赖的是顶层依赖的依赖网络的一部分...有许多工具能帮我们达成这一点： 使用 pnpm：与 yarn、npm 不同，pnpm 不是简单的扁平化结构，而是使用符号链接将物理存储的依赖链接到项目的 node_modules 目录，确保每个项目只能访问在其...使用 Pnpm 在 JS 社区，目前比较主流的包管理器有：NPM、Yarn、Pnpm 三种，从底层实现逻辑来说，更推荐使用 Pnpm (Performance NPM)，它安装下来的依赖结构更合理，能避开大多数幽灵依赖问题
What 什么是 pnpm？ 答：简单理解 pnpm 就是 npm、yarn 的同类竞争对手，是一款现代包管理器。 Why 那为什么要选 pnpm ，而不是 npm 或 yarn 呢？...当安装软件包时，其包含的所有文件都会硬链接自此位置，而不会占用 额外的硬盘空间。 这让你可以在项目之间方便地共享相同版本的依赖包。 安装包速度快 安装包速度有多快呢？...依赖分身 依赖分身指的是：相同版本的依赖被重复安装 在上例基础上，我们假设再新增两个依赖关系：A 和 D 都依赖 B@1.0.0、C 和 E 都依赖 B@2.0.0 关系演变成： node_modules...pnpm 则是通过使用符号链接的方式仅将项目的直接依赖项添加到 node_modules 的根目录下。既保证了安全性，又解决了非法访问依赖、不确定性、重复安装的问题。 Where 官方文档地址？...答：Zoltan Kochan 首先他看到了 yarn 对 npm 在一致性、安全性、离线安装和性能方面的问题的解决，然后再在这个基础上，采用硬链接和软链接的方式，提高了安装速度、节约了磁盘空间、避免了
类似这样的需求在开发过程中屡见不鲜，而这就是为什么我们需要一个包管理器来帮助我们管理这些依赖。...最初，NPM缺乏对依赖版本精确控制和锁文件概念的支持，这正是Yarn诞生的原因。与NPM在功能上有很多相似之处，但Yarn在某些方面提供了更多的优势。...尽管在某些方面它仍然依赖于NPM，但Yarn无疑为JavaScript开发者提供了一个强大而现代化的包管理选择。...有限的原生模块支持：可能存在一些与依赖于NPM特定功能的某些原生模块的兼容性问题。 对全局存储的依赖：PNPM的全局包存储提供了效率优势，但也可能引入潜在的管理开销。...PNPM的全局存储和链接机制可以显著减少重复依赖的存储，使其在速度和磁盘效率上胜过其他选项。 成熟的生态系统：如果你需要接入更广泛的社区和丰富的资源库，NPM可能是更好的选择。
为什么要有 npx？什么场景使用？...当软件包被被安装时，包里的文件会硬链接到这一位置，而不会占用额外的磁盘空间。这允许你跨项目地共享同一版本的依赖。 因此，您在磁盘上节省了大量空间，这与项目和依赖项的数量成正比，并且安装速度要快得多！.../zh/cli/add 整理: 列举几个常用命令，其他命令大家参考上面的官网链接 pnpm add 安装软件包及其依赖的任何软件包。...别名: i pnpm update pnpm update 根据指定的范围更新软件包的最新版本。 在不带参数的情况下使用时，将更新所有依赖关系。...使用心得 https://zhuanlan.zhihu.com/p/546400909 关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn?
它允许将多个包组织在同一个版本控制存储库中，通过统一依赖版本解决了版本冲突问题，同时通过共享顶层 node_modules 目录，有效减小了磁盘占用。...「优点：」 「快速的安装和执行：」 pnpm 利用了硬链接和符号链接的方式，使得依赖的安装和执行更加迅速。 「磁盘空间节省：」 通过依赖共享机制，pnpm 节省了大量磁盘空间。...通过符号链接进行高效的依赖管理。 1、高效的依赖管理 2、易于上手 1、功能相对比较单一 2、需要适应符号链接的概念 「Yalc」 允许在不发布到npm仓库的情况下共享本地包，适用于本地开发和测试。...这就会造成「幽灵依赖」现象，导致项目的依赖关系不够清晰，给开发者带来一定困惑。...相比之下，Pnpm 的依赖树结构更符合常规认知，整个依赖关系更加透明和可控。因此，最终我们决定选择 Pnpm 作为 Monorepo 项目的依赖管理工具。
为什么是三层，而不是两层或者四层呢？...依赖文件三层寻址的目的 第一层 接着上面的例子思考，第一层寻找依赖是 nodejs 或 webpack 等运行环境/打包工具进行的，他们的在 node_modules 文件夹寻找依赖，并遵循就近原则，所以第一层依赖文件势必要写在...幻影依赖 幻影依赖是指，项目代码引用的某个包没有直接定义在 package.json 中，而是作为子依赖被某个包顺带安装了。...但还有一种更难以解决的幻影依赖问题，即用户在 Monorepo 项目根目录安装了某个包，这个包可能被某个子 Package 内的代码寻址到，要彻底解决这个问题，需要配合使用 Rush，在工程上通过依赖问题检测来彻底解决...全局安装目录 pnpm-store 的组织方式 pnpm 在第三层寻址时采用了硬链接方式，但同时还留下了一个问题没有讲，即这个硬链接目标文件并不是普通的 NPM 包源码，而是一个哈希文件，这种文件组织方式叫做
pnpm 文档 前言 在一个 node 项目中免不了 node_modules 依赖，假设项目 A 用的了 Express 依赖，同时项目 B 也用到了 Express，并且两者所存放的位置不同，那么磁盘空间将会多出两份...盘路径下，不然将会在C:\Users\{userDir}\.pnpm-store\v3去管理你的所有依赖，至于为什么后文会说，这里选择 F 盘进行安装，安装结果如下。...window 的硬链接，而读取的就是存放在F:\.pnpm-store\v3下的依赖。...同时.pnpm-store 是根据你所在驱动器（这里是 F 盘）下创建的，可以通过 pnpm store path查看，也就是上文为什么说不要在 C 盘路径（包括桌面）去安装依赖了，所以不用担心 C 盘空间会越来越小...参考链接：关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn? - 掘金 (juejin.cn)
的使用 为什么用pnpm 关于为什么越来越多的人推荐使用pnpm,可以参考这篇文章[1] 这里简单列一下pnpm相对于yarn/npm的优势： 安装速度最快（非扁平的包结构，没有yarn/npm的复杂的扁平算法....pnpm/bar/node_modules/bar@*.*.* bar的依赖包foo会被提升到.pnpm的根目录下，其他包依赖foo时也会软链接到这里 而bar和foo实际通过硬链接到.pnpm store...还有一个巧妙的设计就是：将安装包和依赖包放在同一级目录下，即.pnpm/依赖包/node_modules下。...指定项目运行的Node、pnpm版本 为了减少因node或pnpm的版本的差异而产生开发环境错误，我们在package.json中增加engines字段来限制版本。...，都会同步修改到相同的版本 "linked": [], // 设置一组需要关联版本的包 有依赖关系或有修改的包会同步更新到相同版本 未修改且无依赖关系的包则版本不做变化 "access": "public
接着，从 npm3 开始，包括 yarn，都着手来通过扁平化依赖的方式来解决这个问题。相信大家都有这样的体验，我明明就装个 express，为什么 node_modules里面多了这么多东西？ ?...node_modules目录下，不再有很深层次的嵌套关系。...并且 express 的依赖都在.pnpm/express@4.17.1/node_modules下面，这些依赖也全都是软链接。...再看看.pnpm，.pnpm目录下虽然呈现的是扁平的目录结构，但仔细想想，顺着软链接慢慢展开，其实就是嵌套的结构！...举例如下: // 移除 axios pnpm uninstall axios --filter package-a pnpm link 将本地项目连接到另一个项目。注意，使用的是硬链接，而不是软链接。
幻影依赖指的是 node_modules 中的依赖包在没有 package.json 中声明的情况下使用了其他包的依赖 依赖结构的不确定性。这里为什么是 D@2.0.0 提升，而不是 D@10.0？...通过软链接到.pnpm 目录中 .pnpm 虚拟存储目录——.pnpm，所有直接和间接依赖项都链接到此目录中。...Store pnpm在全局通过Store来存储所有的 node_modules 依赖，并且在 .pnpm 中存储项目的hard links 在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 sotre...社区还没那么活跃 硬链接在 window 系统有兼容性的问题 more… 总结 pnpm 通过巧妙硬链接 + 软链接结合的方式完全实现了依赖树结构的 node_modules，并且严格遵循了 Node.js...并且通过全局只保存一份在 ~/.pnpm-store 的方式，在不同的项目中进行 install 的速度也会变得更快，也解决了磁盘空间占用的问题 参考资料 pnpm: 最先进的包管理工具[6] 中文官网
领取专属 10元无门槛券
手把手带您无忧上云
