npm 与 依赖管理中的细节

npm 7.0 新特性

monorepo 解决方案的横向对比

当下我们开发大型项目的时候越来越多的用到了monorepo 解决方案，而目前最常见的 monorepo 解决方案是 Lerna 和 yarn 的 workspaces 特性。

• lerna 优点是拥有「统一工作流」方面的实现。缺点是依赖提升具有局限性，还是不能很好的解决依赖爆炸的问题（lerna 直接以字符串对比 dependency 的版本号，完全相同才提升，semver 约定在这并不起作用）

• yarn 可以在 package.json 中以 workspaces 字段声明 packages，yarn 就会以 monorepo 的方式管理 packages。相比 lerna，yarn 突出的是对依赖的管理，包括 packages 的相互依赖、packages 对第三方的依赖，yarn 会以 semver 约定来分析 dependencies 的版本，安装依赖时更快、占用体积更小；

• 大多 monorepo 即会使用 lerna 又会在 package.json 声明 workspaces。这样的话，无论你的包管理器是 npm 还是 yarn，都能发挥 monorepo 的优势；

npm/yarn 依赖的演变历史

npm2: npm3: npm 3 会遍历所有的节点，逐个将模块放在 node_modules 的第一层，当发现有重复模块时，则丢弃， 如果遇到某些依赖版本不兼容的问题，则继续采用 npm 2 的处理方式，前面的放在 node_modules 目录中，后面的放在依赖树中。举个?：A，B，依赖 D(v 0.0.1)，C 依赖 D(v 0.0.2): 但是 npm 3 会带来一个新的问题：由于在执行 npm install 的时候，按照 package.json 里依赖的顺序依次解析，上图如果 C 的顺序在 A，B 的前边，node_modules 树则会改变，会出现下边的情况：

package.json 的不足之处

npm install 执行后，会生成一个 node_modules 树，在理想情况下， 希望对于同一个 package.json 总是生成完全相同 node_modules 树。在某些情况下，确实如此。但在多数情况下，npm 无法做到这一点。有以下两个原因： 1）某些依赖项自上次安装以来，可能已发布了新版本 。比如：A 包在团队中第一个人安装的时候是 1.0.5 版本，package.json 中的配置项为 A: '^1.0.5'；团队中第二个人把代码拉下来的时候，A 包的版本已经升级成了 1.0.8，根据 package.json 中的 semver-range version 规范，此时第二个人 npm install 后 A 的版本为 1.0.8；可能会造成因为依赖版本不同而导致的 bug； 2）针对 1）中的问题，可能有的小伙伴会是把 A 的版本号固定为 A: '1.0.5' 不就可以了吗？但是这样的做法其实并没有解决问题， 比如 A 的某个依赖在第一个人下载的时候是 2.1.3 版本，但是第二个人下载的时候已经升级到了 2.2.5 版本，此时生成的 node_modules 树依旧不完全相同 ，固定版本只是固定来自身的版本，依赖的版本无法固定。

针对 package.json 不足的解决方法

为了解决上述问题以及 npm 3 的问题，在 npm 5.0 版本后，npm install 后都会自动生成一个 package-lock.json 文件 ，当包中有 package-lock.json 文件时，npm install 执行时，如果 package.json 和 package-lock.json 中的版本兼容，会根据 package-lock.json 中的版本下载；如果不兼容，将会根据 package.json 的版本，更新 package-lock.json 中的版本，已保证 package-lock.json 中的版本兼容 package.json。

lock 文件构成与作用

构成： docs.npmjs.com/cli/v6/conf…

• version ：包版本，即这个包当前安装在 node_modules 中的版本
• resolved ：包具体的安装来源
• integrity ：包 hash 值，验证已安装的软件包是否被改动过、是否已失效
• requires ：对应子依赖的依赖，与子依赖的 package.json 中 dependencies 的依赖项相同
• dependencies ：结构和外层的 dependencies 结构相同，存储安装在子依赖 node_modules 中的依赖包

需要注意的是，并不是所有的子依赖都有 dependencies 属性，只有子依赖的依赖和当前已安装在根目录的 node_modules 中的依赖冲突之后，才会有这个属性。 作用：

• 在团队开发中，确保每个团队成员安装的依赖版本是一致的，确定一棵唯一的 node_modules 树；
• node_modules 目录本身是不会被提交到代码库的，但是 package-lock.json 可以提交到代码库，如果开发人员想要回溯到某一天的目录状态，只需要把 package.json 和 package-lock.json 这两个文件回退到那一天即可。
• 由于 package-lock.json 和 node_modules 中的依赖嵌套完全一致，可以更加清楚的了解树的结构及其变化。
• 在安装时，npm 会比较 node_modules 已有的包，和 package-lock.json 进行比较，如果重复的话，就跳过安装 ，从而优化了安装的过程。

依赖的类型

npm 目前支持以下几类依赖包管理包括

• dependencies

  • dependencies 是无论在开发环境还是在生产环境都必须使用的依赖

• devDependencies

  • devDependencies 是指可以在开发环境或者测试环境使用的依赖

• optionalDependencies 可选择的依赖包

  • ptionalDependencies 指的是可以选择的依赖，当你希望某些依赖即使下载失败或者没有找到时，项目依然可以正常运行或者 npm 继续运行的时，就可以把这些依赖放在 optionalDependencies 对象中，但是 optionalDependencies 会覆盖 dependencies 中的同名依赖包，所以不要把一个包同时写进两个对象中。

• peerDependencies 同等依赖

  • peerDependencies 用于指定你当前的插件兼容的宿主必须要安装的包的版本

• bundledDependencies 捆绑依赖包

  • 这个依赖项也可以记为 bundleDependencies，与其他几种依赖项不同，他不是一个键值对的对象，而是一个数组，数组里是包名的字符串，例如：

{ 
  "name": "project", 
  "version": "1.0.0", 
  "bundleDependencies": [ 
    "axios",  
    "lodash" 
  ] 
}

• 当使用 npm pack 的方式来打包时，上述的例子会生成一个 project-1.0.0.tgz 的文件，在使用了 bundledDependencies 后，打包时会把 Axios 和 Lodash 这两个依赖一起放入包中，之后有人使用 npm install project-1.0.0.tgz 下载包时，Axios 和 Lodash 这两个依赖也会被安装。需要注意的是安装之后 Axios 和 Lodash 这两个包的信息在 dependencies 中，并且不包括版本信息。

"bundleDependencies": [ 
    "axios", 
    "lodash" 
  ], 
  "dependencies": { 
    "axios": "*", 
    "lodash": "*" 
  },

• 如果我们使用常规的 npm publish 来发布的话，这个属性是不会生效的，所以日常情况中使用的较少。

yarn install

classic.yarnpkg.com/en/docs/cli…

参考文献： github.blog/2020-10-13-… github.com/npm/rfcs/bl… docs.npmjs.com/specifying-… classic.yarnpkg.com/en/docs/cli… classic.yarnpkg.com/zh-Hans/doc… docs.npmjs.com/cli/v6/conf…