一文聊聊Node包管理发展的五个阶段

青灯夜游

发布时间：2022-12-26 19:46:43

2612人浏览过

来源于掘金社区

转载

从2009年 node 诞生至今，node 生态发展繁荣，围绕 node 生态衍生出的 node 包管理器百花齐放，先后出现了 npm、kpm、pnpm、yarn、cnpm 等等。实际上 node 包管理器发展主要分5个阶段，下面我们一起看下每个阶段的关键特征和代表产物吧~

阶段一：刀耕火种

正确来说，Node是不存在没有包管理器时期的，2009年，Node.js 问世时 npm的雏形也发布了。【相关教程推荐：nodejs视频教程、编程教学】

npm 全称 Node.js Package Manager；从A brief history of Node.js 里面可以看到

2009 
Node.js is born 
The first form of npm is created

下面聊一下没有出现Node包管理器时期是怎样的，那时候做的更多的事情就是

网上寻找各软件的官网，比如 jQuery；
找到下载地址，下载 zip 包；
解压，放到项目中一个叫 libs 的目录中；
想更方便的话，直接将 CDN 链接粘贴到 HTML 中

那时候模块化管理？版本号管理？依赖升级？都不存在的！

阶段二：嵌套安装

2009 年，Node.js 诞生，npm的雏形也正在酝酿，2011年发布了 1.0 版本；npm是围绕着语义版本控制 semver 的思想而设计的，默认认为Node包开发者，在升级依赖包自定义版本号时，都会按照 semver 规范升级版本号。

代名词： Node包管理规范化、node_modules 目录嵌套存放依赖

代表产物： npm v1、v2 版本

关键特点：

（1）依赖包嵌套安装，相同版本的依赖会被冗余安装

（2）依赖包安装不确定性：默认装最新次版本的依赖包（可设置固定版本）

（3）串行安装依赖，速度慢；不支持离线缓存

解释1：依赖 嵌套安装 ，如果A依赖B、B依赖C，node_modules目录如下

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

问题： 依赖嵌套过多会造成嵌套地狱，与此同时会出现大量相同依赖包的冗余安装，造成 node_modules 体积过大，需要程序员定期的 rm -rf node_modules，但windows系统，很多程序无法处理超过260个字符的文件路径名，早期 npm 的 windows 用户都见过这个弹窗

解释2：针对每次 npm install 默认安装最新次版本依赖，造成的依赖安装 不确定性 问题：

semver 规范了版本号构成：X.Y.Z-[state]，版本号升级规范如下

X 是主版本号： API 产生的变化，与旧版本不兼容时，升级主版本号
Y 是次版本号：增加了新的API，但向后兼容，升级次版本号
Z 是补丁版本号：当做了向后兼容的缺陷修复的时候
state 可以是：alpha（内测）、beta（公测）、gamma（相当成熟的测试版）、rc（预发布）

版本不确定原因：执行 npm 默认安装依赖指令时，npm 认为开发者都会遵循 semver 版本升级规范，直接给开发者安装了最新次版本的依赖包

解决方案1：可以通过npm config set save-exact true命令关闭在版本号前面使用 ^的默认行为
总结：无法解决依赖库自己的依赖默认安装最新次版本的问题

解决方案2：npm提供了 shrinkwrap 命令，会生成一个 npm-shrinkwrap.json 文件，为所有库和所有嵌套依赖的库记录精准的版本
总结：锁文件不会默认生成，需要用户手动执行指令；依赖于用户知道这个指令，相对繁琐

阶段三：扁平化安装

2015年，为解决 npm1、npm2 存在的嵌套安装、版本不规定问题，完全重写了 npm 程序

代名词： 较少冗余依赖的安装、node_modules 目录扁平化存放依赖

代表产物： npm v3版本

原理简述： npm install时，先构建依赖树再将所有依赖都安装在 node_modules 根目录，子依赖遇到不同版本的重名依赖时，会将子依赖安装在自己node_modules下

关键特点：

（1）减少冗余安装：依赖扁平化安装，一定情况下减少了冗余包的安装

存在的问题：

（1）“幽灵依赖”、“幻影依赖” 问题

（2）“双胞胎陌生人” 、“依赖包分身” 问题

（3）目录不固定：依赖的安装顺序，决定了 node_module 目录结构

解释1：依赖的依次安装顺序，决定了node_modules 目录结构

如下场景： App1 依赖 packageA 和 packageC 和 packageG 和 packageH，而 packageA 和 packageC 都依赖了 packageB v1.0，packageG、packageH 都依赖 packageB 的 v2.0 版本

如果先安装 packageA 或 packageC，node_modules 目录如下

如果先安装 packageG 或 packageH，node_modules 目录如下

针对如上情况，npm 提供了指令 npm dedupe，可以手动整理&简化 node_modules 的目录结构，整理后的 node_modules 目录结构是一致的，不受依赖包安装顺序影响

解释2：不一定能减少冗余包的安装

通过举例1，可以看出虽然依赖包扁平化安装，但仍存在相同版本的依赖包，有冗余包

解释3：“双胞胎陌生人” 问题

参考举例1中，相同版本的依赖包，被安装两次，被放置到两处，这种现象被称为“双胞胎陌生人”

解释4：“幽灵依赖” 问题

node_modules 一级目录下的依赖包，开发者可以直接使用，但依赖包没定义在 package.json 中，这样的依赖包被称为 “幽灵依赖”，前端项目中使用 “幽灵依赖”，后期可能会出现问题。

因为后期可能伴随着其他依赖的升级移除了这个“幽灵依赖”，此时 node_modules 中就不存在了，执行 npm install 时，并不会主观的去安装 “幽灵依赖”，导致项目找不到依赖包，然后报错。

阶段四：安全、提速

2016年，yarn、pnpm release 版本相继出现，在一定程度上解决了之前的安装版本不确定、安装速度慢等问题，yarn 率先推出的能力相比于 npm，更夺人眼球，保证了一致性&安全性，提升了安装速度

代名词： 依赖安装相对安全、提速

代表产物： yarn release版本、pnpm release版本、npm v5 版本（npm v4没有太大变化，v5向前迈了一大步）

关键特点：

（1）安全：默认生成版本锁文件，保证了每次安装依赖版本都一样

（2）提速：增加了缓存离线安装、并行安装、安装异常后自动重试

（3）workspace：yarn从v1版本开始支持，可以高效管理多个项目的依赖包；npm v7才支持 workspace

存在的问题：

（1）幽灵依赖

（2）依赖包单项目重复安装、跨项目重复安装

（3）目录不固定：依赖的安装顺序，决定了 node_module 目录结构

解释1：关于安全

yarn v0.x 版本率先、npm v5.x 版本紧跟其后，下载依赖时，默认生成依赖锁文件，精确地将版本锁定在一个值

yarn 的 .lock 文件：只是记录安装的依赖版本，需要结合 package.json 来确定 node_modules 目录结构
npm 的 .lock 文件：记录了安装的依赖版本及 node_modules 目录结构

总结： 避免了不同终端安装依赖时版本不一致问题，但“依赖幽灵” 问题仍然存在

解释2：关于提速 - 离线缓存

npm v2版本就支持了缓存，但需要联网检测，才能使用缓存的依赖

yarn v0.x版本率先支持了离线缓存，从网络下载的包都会缓存到全局，下次安装优先从本地找，找到直接copy

npm v5版本重写了缓存系统，也支持了离线安装，安装速度大大提升

解释3：关于提速 - 并行安装

yarn 率先支持了依赖包并行安装，此前 npm 串行安装依赖，后来 npm 也优化了并行安装

解释4：安装依赖后，自动整理 node_modules 目录

起始时间：yarn v1.x 版本、npm v4.x 版本

如果项目中删除了 .lock 文件，初始化安装依赖时，会自动整理 node_modules 目录；npm v4.x之前版本，需要用户手动执行指令 npm dedupe整理依赖目录
由于 node_modules 是扁平化管理依赖，深层依赖可能会被安装到一级目录下；当项目中再安装不同版本的依赖时，遇到依赖版本冲突，会自动将深层依赖从一级目录移动到父依赖目录下 【已验证】