杜绝使用 npm

作者: littleyu | 来源:发表于2022-02-13 20:47 被阅读0次

管理器

npm，太慢了，总会有莫名的bug，需要删除 node_modules，在次安装以后才能解决。
cnpm，已经淘汰。
yarn / yarnPnP，比 npm 快很多，比 npm 做了很多的优化，但是还存有和 npm 一样的其他问题。
pnpm，更快，且解决了 npm/yarn 内部潜在的 bug，并且极大了地优化了性能，扩展了使用场景。

npm

node 自带

为什么 node 要选择 npm？
在远古时代，前端是通过网址来共享代码，比如你想使用 jQuery，那么你点击 jQuery 网站上提供的链接就可以下载 jQuery，放到自己的网站上使用。
但是当项目的依赖越来越多的时候，这是一件很麻烦的事情，去 jQuery 官网下载 jQuery，去 BootStrap 官网下载 BootStrap...等等。
程序员 Isaac Z. Schlueter 给出一个解决方案：用一个工具把这些代码集中到一起来管理吧！毕竟懒才是程序员的第一生产力。

NPM 的思路大概是这样的：

买个服务器作为代码仓库（registry），在里面放所有需要被共享的代码
发邮件通知 jQuery、Bootstrap、Underscore 作者使用 npm publish 把代码提交到 registry 上，分别取名 jquery、bootstrap 和 underscore（注意大小写）
社区里的其他人如果想使用这些代码，就把 jquery、bootstrap 和 underscore 写到 package.json 里，然后运行 npm install ，npm 就会帮他们下载代码
下载完的代码出现在 node_modules 目录里，可以随意使用了。

发展

Isaaz 通知 jQuery 作者 John Resig，他会答应吗？这事儿不一定啊，对不对。
只有社区里的人都觉得「npm 是个宝」的时候，John Resig 才会考虑使用 npm。
那么 npm 是怎么火的呢？
npm 的发展是跟 Node.js 的发展相辅相成的。
Node.js 是由一个在德国工作的美国程序员 Ryan Dahl 写的。他写了 Node.js，但是 Node.js 缺少一个包管理器，于是他和 npm 的作者一拍即合、抱团取暖，最终 Node.js 内置了 npm（现在来看为什么 npm 这么烂，node 还要选择它，当时的 node 觉得自己 i/o 很快，且当时的程序还没有这么复杂）。后来的事情大家都知道，Node.js 火了。
所以说一门技术想要流行就得攀附、组合，NPM 全称 node package manager。（类似 LAMP，之前在编程历史中讲过）

yarn

安装 yarn

首先不推荐使用 npm 安装
为什么？

Yarn 团队认为 npm 不安全且不可靠，根据Yarn项目维护者的说法，通过npm安装Yarn违反了项目目标，可能会引起问题，并且通常比特定于平台的安装方法更糟糕。

一般不推荐通过 npm 安装 Yarn。使用 npm 安装 Yarn 是不确定的，包没有签名，唯一执行的完整性检查是基本的 SHA1 哈希，这在安装系统范围的应用程序时是一个安全风险。

通过 npm 运行 Yarn，它是一个单独的包管理器实用程序，可能会导致边缘问题（请参阅issue 2072）

通过系统包管理器安装将 Yarn 与 npm 分离，允许您在没有 npm 的情况下运行 Yarn

系统包管理器通常会定期运行，保持 Yarn 更新

通过 npm 安装 Yarn 很慢

但是从 Yarn 2.x 开始，Yarn 团队改变了他们的建议，现在建议通过 npm 安装该工具。此建议围绕锁定每个项目使用的 Yarn 版本的优势。这使项目能够适应不同版本的 Yarn 的变化。

pnpm（performant npm）

安装 pnpm

npm i -g pnpm

详解

安装时

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

将依赖包的版本区间解析为某个具体的版本号
下载对应版本依赖的 tar 包到本地离线镜像（能够在无网环境下安装，npm 5+ 才抄袭过来）
将依赖从离线镜像解压到本地缓存
将依赖从缓存拷贝到当前目录的 node_modules 目录

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

速度

很明显 npm 是最慢的。
为什么慢，因为 node_modules，文件小而多，磁盘 I/O 的特别慢，而且重复下载的文件也会在有多。

包管理方式

依赖版本

npm包管理工具都是通过 package.json 中对各个依赖包的描述去下载对应的依赖包的。
但 package.json 只能规定大版本号。这样就会导致每个时期下载的依赖包都是不一样的，很容易出现兼容性等各种问题。例如：

"dependencies": {
  "vue": "^3.2.6"
}

字符 ^ 告诉 NPM 检查在 3.X.X 范围内是否有较新版本，如果有，则进行安装。类似地，~ 字符只会出现在热修复程序或 3.2.X 上。
这样导致项目每次安装的时候版本不一致，可能引起一些相关错误。
而 yarn 率先发明了 lockfiles（已被 npm 5+ 抄袭）。
规定了具体每个依赖包的版本号和对应的下载路径，保证我们下次在重新安装依赖时，能跟上次一模一样。

// package-lock.json，npm 是 json 文件，方便看得懂
"vue": {
  "version": "3.2.6",   
  "resolved": "https://registry.npmjs.org/vue/-/vue-3.2.6.tgz",   //下载路径
  "integrity": "sha512-Zlb3LMemQS3Xxa6xPsecu45bNjr1hxO8Bh5FUmE0Dr6Ot0znZBKiM47rK6O7FTcakxOnvVN+NTXWJF6u8ajpCQ==",   
  "requires": {
    "@vue/compiler-dom": "3.2.6",
    "@vue/runtime-dom": "3.2.6",
    "@vue/shared": "3.2.6"
  }
}

目录结构

如果一个项目有 100 个依赖，并且这些依赖的依赖都有 lodash。
在 npm 中 lodash 很可能就被安装了 100 次，磁盘中就有 100 个地方写入了这部分代码。所以这能不能优化呢？
而在 yarn 中会实行的是扁平结构（已被 npm 3+ 抄袭）。

# ① 假设项目依赖a,b,c三个模块，依赖树为:
#  +- a
#    +- react@15
#  +- b
#    +- react@16
#  +- c
#    +- react@16
# yarn安装时会按照项目被依赖的次数作为权重，将依赖提升(hoisting)，
# 安装后的node_modules结构为:
  .
  └── node_modules
      ├── a
      │   ├── index.js
      │   ├── node_modules
      │   │   └── react  # @15
      │   └── package.json
      ├── b
      │   ├── index.js
      │   └── package.json
      ├── c
      │   ├── index.js
      │   └── package.json
      └── react  # @16 被依赖了两次，所以进行提升

这样一来，重复的包将会大量减少，但是由于“提升”，当你只安装一个依赖的时候，会发现 node_modules 下多了很多的你没有安装的目录（因为重复的被提升了），node_modules 目录将会变得很丑。
Q：为什么不一起把 react15 也一起提升了？
A：因为 node_modules 不能有效地处理重复的包. 两个名称相同但是不同版本的包是不能在一个目录下共存的。
-而且这里还有一个潜在的问题，即：如果 A 依赖 B， B 依赖 C，由于提升了那么 A 当中是可以直接使用 C 的，但问题是 A 当中并没有声明 C 这个依赖，因此会出现这种非法访问的情况（其中也有因为Node没有包的概念的关系，我猜测可能和 js 是一门运行时的语言有关）。
接下来在看两种情况：

# ② 现在假设在①的基础上，根项目依赖了react@15，对于项目自己的依赖肯定是要放在node_modules根目录的，
# 由于一个目录下不能存在同名目录，所以react@16没有的提升机会. 
# 安装后node_moduels结构为
  .
  └── node_modules
      ├── a
      │   ├── index.js
      │   └── package.json # react@15 提升
      ├── b
      │   ├── index.js
      │   ├── node_modules
      │   │   └── react  # @16
      │   └── package.json
      ├── c
      │   ├── index.js
      │   ├── node_modules
      │   │   └── react  # @16
      │   └── package.json
      └── react  # @15
# 上面的结果可以看出，react@16出现了重复

  .
  └── node_modules
      ├── a
      │   ├── index.js
      │   ├── node_modules
      │   │   └── react  # @16
      │   └── package.json
      ├── b
      │   ├── index.js
      │   ├── node_modules
      │   │   └── react  # @15
      │   └── package.json
      └── react  # @15 or 16?
# 答案是: 都有可能。取决于 a 和 b 在 package.json中的位置，如果 a 声明在前面，那么就是提升的就是 react@16，否则是react@15。

所以这种扁平化结构存在的缺点有：一、依赖结构的不确定性。二：扁平化算法本身的复杂性很高，耗时较长。三：项目中仍然可以非法访问没有声明过依赖的包。四：在某些情况下没有很好的解决重复问题。
因此 yarn 又做出了改进，加入的 PnP（Plug'n'Play） 功能，1.12 版本开始默认包含，2.0 版本开始默认开启。
基本原理：Yarn 作为一个包管理器，它知道你的项目的依赖树. 那能不能让 Yarn 告诉 Node? 让它直接到某个目录去加载模块。这样即可以提高 Node 模块的查找效率，也可以减少 node_modules 文件的拷贝。
在 pnp 模式下，Yarn 不会创建 node_modules 目录，取而代之的是 .yarn 目录和 .pnp.js文件。
.pnp.js 文件，这个文件包含了项目的依赖树信息，模块查找算法，也包含了模块查找器的 patch 代码(在 Node 环境，覆盖 Module._load 方法)，简单来说就是项目的npm模块解析规则。
.yarn 目录存放了项目中下载的所有依赖的zip包。
使用 pnp 机制的以下优点：
1. 摆脱了 node_modules：
  - 时间上: 相比较在热缓存(hot cache)环境下运行yarn install节省 70%的时间。
  - 空间上: pnp 模式下，所有 npm 模块都会存放在全局的缓存目录下，依赖树扁平化，避免拷贝和重复。
2. 提高模块加载效率，Node 为了查找模块，需要调用大量的 stat 和 readdir 系统调用。. pnp 通过 Yarn 获取或者模块信息，直接定位模块。
3. 不再受限于 node_modules 同名模块不同版本不能在同一目录。
使用 pnp 机制的以下缺点
1. 因为 node 依赖解析的目录 node_modules 没了，不能直接使用 node xxx.js。
2. 由于还是不够成熟（2018.9面世），前端社区其他工具链支持度还不够，从官方看已有下列的工具有条件支持(某版本起或插件支持)。
但 pnpm 内部使用基于内容寻址的文件系统来存储磁盘上所有的文件，他只会安装一次，磁盘中只有一个地方写入（rails 也类似这样），后面再次使用都会直接使用 hardlink（硬链接），这种方法几乎就解决了上面的所有问题。
例如我们安装一个依赖：pnpm init -y && pnmp i react

  .
  └── node_modules
  │    ├── .pnpm
  │    ├── react
  │    ├── .modules.yaml
  └── package.json
  └── pnpm-lock.yaml # lockfiles

如此整洁、干净，我们直接就看到了 react，但值得注意的是，这里仅仅只是一个软链接，那么它真正的位置在哪呢？
.pnpm 当中寻找：

  .
  └── node_modules
        ├── .pnpm
              ├ node_modules
              ├ registry.npmjs.org+@js+tokens@4.0.0
              ├ .......
              ├ registry.npmjs.org+react@17.0.2
                  ├ node_modules
                      ├ loose-envify (软链接)
                      ├ ... (软链接)
                      ├ react
                        ├ cjs
                        ├ umd
                        ├ ......

好家伙！竟然在 .pnpm/egistry.npmjs.org+react@17.0.2/node_modules/react 下面找到了！同级其他的依赖也都是软链接。
再看看.pnpm，.pnpm目录下虽然呈现的是扁平的目录结构，但仔细想想，顺着软链接慢慢展开，其实就是嵌套的结构！
将包本身和依赖放在同一个node_module下面，与原生 Node 完全兼容，又能将 package 与相关的依赖很好地组织到一起，设计十分精妙，也解决了 yarn PnP 没有 node_modules 的问题。
这么好的东西为什么没有人用呢？
- 兼容问题，像 hard link 和 symlink 这种方式在所有的系统上都是兼容的吗？实际上 hard link 在主流系统上(Unix/Win)使用都是没有问题的，但是 symlink 即软连接的方式可能会在 windows 存在一些兼容的问题，但是针对这个问题，pnpm 也提供了对应的解决方案：在 win 系统上使用一个叫做 junctions 的特性来替代软连接，这个方案在 win 上的兼容性要好于 symlink。
- 或许你也会好奇为啥 pnpm 要使用 hard links 而不是全都用 symlink 来去实现。
- 实际上存在 store 目录里面的依赖也是可以通过软连接去找到的，nodejs 本身有提供一个叫做 --preserve-symlinks 的参数来支持 symlink，但实际上这个参数实际上对于 symlink 的支持并不好导致作者放弃了该方案从而采用 hard links 的方式。具体可以参考该 issue。

monorepo

只有 pnpm 支持。
npm(npm 7+ 抄袭)/yarn workspace
随着前端工程的日益复杂，越来越多的项目开始使用 monorepo。之前对于多个项目的管理，我们一般都是使用多个 git 仓库，但 monorepo 的宗旨就是用一个 git 仓库来管理多个子项目，所有的子项目都存放在根目录的packages目录下，那么一个子项目就代表一个package。如果你之前没接触过 monorepo 的概念，建议仔细看看这篇文章(https://www.perforce.com/blog/vcs/what-monorepo)以及开源的 monorepo 管理工具lerna(https://github.com/lerna/lerna#readme)，项目目录结构可以参考一下 babel 仓库(https://github.com/babel/babel)。
pnpm 体现在各个子命令的功能上，比如在根目录下 pnpm add A -r，那么所有的 package 中都会被添加 A 这个依赖，当然也支持 --filter 字段来对 package 进行过滤。

目前我们为什么使用 yarn

因为 npm 太慢了。
从目前主流的开源项目来看，几乎没有使用 npm 的仓库，一般都是 yarn。
团队内需要统一，如果不一致可能会出现依赖问题(npm 和 yarn 的 lock 文件不同)。

杜绝使用 npm

管理器

npm

NPM 的思路大概是这样的：

发展

yarn

安装 yarn

pnpm（performant npm）

安装 pnpm

详解

安装时

速度

包管理方式

依赖版本

目录结构

monorepo

目前我们为什么使用 yarn

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读