关于现代包管理器的深度思考

要分为两个部分, 首先，执行 npm/yarn install之后，包如何到达项目 node_modules 当中。其次，node_modules 内部如何管理依赖。

执行命令后，首先会构建依赖树，然后针对每个节点下的包，会经历下面四个步骤:

- 1. 将依赖包的版本区间解析为某个具体的版本号

- 2. 下载对应版本依赖的 tar 包到本地离线镜像

- 3. 将依赖从离线镜像解压到本地缓存

- 4. 将依赖从缓存拷贝到当前目录的 node_modules 目录

然后，对应的包就会到达项目的node_modules当中。

那么，这些依赖在node_modules内部是什么样的目录结构呢，换句话说，项目的依赖树是什么样的呢?

在 npm1、npm2 中呈现出的是嵌套结构，比如下面这样:果 bar 当中又有依赖，那么又会继续嵌套下去。试想一下这样的设计存在什么问题:

1. 依赖层级太深，会导致文件路径过长的问题，尤其在 window 系统下。
2. 大量重复的包被安装，文件体积超级大。比如跟 foo 同级目录下有一个baz，两者都依赖于同一个版本的lodash，那么 lodash 会分别在两者的 node_modules 中被安装，也就是重复安装。
3. 模块实例不能共享。比如 React 有一些内部变量，在两个不同包引入的 React 不是同一个模块实例，因此无法共享内部变量，导致一些不可预知的 bug。

接着，从 npm3 开始，包括 yarn，都着手来通过扁平化依赖的方式来解决这个问题。相信大家都有这样的体验，我明明就装个 express，为什么 node_modules里面多了这么多东西?

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!