前端开发人员每天都与XXX安装联系，而Bag Manager是必不可少的工具。
本文将在本文中描述当前主流软件包管理工具NPM，YARN和PNPM的管理策略和进化历史，并且不涉及任何晦涩的代码。
2010年1月，一位名叫NPM的行李经理出生。
许多人认为NPM是节点软件包管理器的缩写。实际上，它不是，npm根本不是任何短语的缩写。
NPM官方谣言：
它的前身实际上是一种称为PM（PKGMAKEINST）的BASH工具，可以在各种平台上安装各种内容。
如果您想说缩写，也应该是节点PM或新PM。
在早期，NPM采用了直接依赖于node_modules的Node_modules结构的巢，而孩子依赖于直接依赖的node_modules。
例如，该项目取决于A和C，而A和C取决于B@1.0和B@2.0的不同版本，Node_modules结构如下：
如果D也取决于b@1.0，则将生成以下嵌套结构：
您可以看到同一版本的B分别由A和D安装了两次。
在真实的场景中，依赖关系的增加以及冗余数据包将变得更加多。node_modules最终将与黑洞相提并论，它将很快填充磁盘。依赖嵌套的深度将是可怕的，这是依靠地狱。
为了使嵌套的依赖性尽可能弄平，以避免过度的依赖关系和数据包冗余，NPM V3依赖于“促销”（提升），并采用平坦的node_modules结构。
可以看出，b@1.0 A的孩子的依赖不再被放置在A的node_modules下，而是与A相同的水平。
C取决于版本编号的b@2.0嵌套在C的node_modules下。
这不会导致大量的袋子安装，并且依赖程度不会太深。它解决了地狱的问题，但也构成了一个新问题。
幽灵依赖性指的是包装中的未出色依赖项。
例如，上面的示例实际上，我们仅安装了A和C：
由于B在安装过程中的提高到与A相同的水平，因此它仍然可以在项目中正常工作。
幽灵依赖性是由依赖性丧失引起的。如果一个版本的A依赖项不再依赖于B或B的版本，则会导致依赖性或兼容性问题。
不确定性是指：json文件，安装可能在依赖之后无法获得相同的node_modules目录结构。
仍然是上一个示例，a依赖于b@1.0，c取决于b@2.0，是否应在安装后增加1.0或2.0。
这取决于用户的安装顺序。
如果包装的更改。
假设继续安装b@1.0的D模块和依赖于 @b2.0的E模块：目前：
以下是b@1.0的node_modules结构：
您可以看到B@2.0将安装两次。实际上，无论是升级到b@1.0还是b@2.0，都将安装B的重复版本。两个重复安装B称为Doppelgangers。
尽管模块C和E取决于b@2.0，但实际上是B. B.假设B在导出之前做一些缓存或副作用，则用户的项目将犯错。
在2016年，Yarn发布了，Yarn还采用了平坦的Node_modules结构。它的出现是解决几个NPM V3的最迫在眉睫的问题：缓慢的安装速度和不确定性。
在NPM中安装依赖项时，安装任务是串行的，并且安装将按软件包的顺序逐一执行，这意味着它将等待完全安装袋子，然后继续下一个。
为了加快包装速度，纱线使用并行操作，并且在性能方面有了显着改善。在缓存机构中，纱线将减慢磁盘上的每个包装。下次安装此软件包时，您可以退出网络以从磁盘上实现离线安装。
纱线的更大贡献是对发明的Yarn.lock发明。
依靠安装时，根据package.josn生成纱线lock文件。
LockFile记录了依赖性以及依赖依赖性版本，以获得地址和验证模块完整性的完整性。
即使在不同的安装序列中，相同的依赖项也可以在任何环境和容器中获得稳定的node_modules目录结构，从而确保依赖性安装的确定。
因此，纱线出现时被定义为快速，安全和可靠的依赖管理。
纱线仍然与NPM相同，与扁平node_modules结构相同，该结构无法解决幽灵依赖和依赖的化身的问题。
PNPM - 表现的NPM，于2017年正式发布，定义为磁盘空间的快速包装管理工具，创建了一种新的依赖性管理机制，成为包装管理的新星。
与依赖关系改进和Flat node_modules不同，PNPM引入了另一组依赖关系：内容地址存储。
此策略将在系统的全局存储中安装软件包，并且每个依赖的版本仅在系统中安装一次。
在引用项目node_modules的依赖关系时，可以通过硬链接和符号链接在全局存储中找到此文件。要实现此过程，node_modules下将有更多目录，这是一个非flat结构。
仍然使用上述A，B和C模块的示例。使用PNPM安装后，NODE_MODULES结构如下：
路径的开头是一个艰难的链接，指向全球商店中安装的依赖关系。
其余的是符号链接，指出依赖的快捷方式。
PNPM的官方图片还清楚地解释了这种机制：
这套新的机制设计集非常聪明，不仅与节点的依赖分析兼容，而且也解决了：
同时，由于链接的优势，在大多数情况下，PNPM的安装速度速度是NPM和纱线的两倍，并且保存了更多的磁盘空间。
但是有一些缺点：
2020年1月，Yarn V2发行了，也称为Yarn Berry（V1称为Yarn Classic）。它是对纱线的重大升级。重要的更新之一是插件播放（插件= Plug and Play = PNP，已插入并播放）。
NPM和Yarn的依赖关系安装和依赖分析都涉及大量文件I/O，这不是有效的。开发Plug'n Play的最直接原因是依靠慢速参考和缓慢的安装。
无论是NPM还是纱线，它都具有缓存的功能。在大多数情况下，在安装依赖项时，缓存中的相关软件包实际上是在node_modules中的项目目录中复制相关软件包。
YARN PNP不复制此步骤，而是在项目中维护静态映射表PNP.CJ。
pnp.cjs记录了缓存中依赖项的特定位置，并且所有依赖关系都具有全局缓存。在同一时间，构建了解析器。依赖依赖时，帮助节点从全局缓存目录中找到依赖项，而不是找到node_modules。
这样，大量的I/O操作将不会同时生成Node_modules目录。相同版本的依赖项只有一个。依赖的安装速度和分析速度将大大提高。
PNPM的V5.9在2020年底也支持PNP。
PNP的缺点更为明显，就是摆脱节点生态学。
目前，没有完美的依赖管理计划。您可以看到，在依赖管理的开发过程中，它似乎是：
图书馆和开发人员可以在优化和创新的过程中相互学习，站在巨人的肩膀上，继续前进，并继续促进前端工程领域的发展。
如果这篇文章对您有帮助，请帮助我喜欢它（更多的关注更好 ^ ^。
请注意我的公共帐户“ Little Li's Front -end Hut”，并变得更加强大！还有什么？
原始：https：//juejin.cn/post/7104088592426729480