趁现在为自己的亲人留份回忆

转眼间,2022 年就快要过去了,这一年对我来说算是过的最快的一年,去年就想写一些内容但是一直没有下得了笔,就一直拖到了现在。

去年九月末,我的祖母突然辞世,那时我刚到新学校,与自己的舍友刚刚熟悉,清楚的记得那天早上我跟同学买了早点,坐在食堂里吃早饭,正好那天第一节课需要交手机,我在食堂跟舍友聊天,父亲突然来电话让我临时转一下钱,仔细一问,祖母突然昏迷了,祖父把我父亲和母亲赶紧叫了过来,我父亲和母亲跟着救护车去了医院,当时我知道后脑袋突然一片空白,他俩安慰我没事,我才赶紧把钱转了过去,但那之后就一直担心,课都听不进去。

记不清什么时候可能是当天或者第二天,再给父亲打电话,医院说祖母是脑溢血,而且目前很危险,当时听完很难受,不知道为什么我来学校前祖母还健健康康,不到一个月突然就出事了,心情很难受,也很担心,自那之后的几天里我抽空就打电话,父亲总是安慰我没事,让我放心好好在学校学习,我也在心里一直期望祖母平安无事,就这样一直到了九月最后几天,那天正好是学校开运动会,早上的风吹的人双腿发凉,我跟舍友去操场的路上一人买了一个座垫,到了地方就坐下唠嗑,到了快十一点多的时候,母亲来电话了,让我跟班主任请假抓紧时间回来,祖母病危了,当时听到后突然有点难以相信,以至于我给班主任打电话的时候都已经不会说话了,我们班任安慰我让我不要着急,我先去复印社打印了离校申请表,每个地方签完字了,我就回到了宿舍收拾东西,这时候母亲又打来电话让我别着急,因为飞机和动车的时间都是固定的,收拾完以后我就背上包到学校外打车到火车站,一个人坐在火车站座椅上,抬头望着天花板想着以前跟祖母的点点滴滴,慢慢眼泪就流了出来,火车到站了,我又坐着地铁去飞机场,这一路上脑袋里已经记不起都想了些什么,在飞机上哭了不知道多少回,但都是哭哭停停抽泣,终于回来了,阿姨和我母亲接的我,我上了车母亲没说话,阿姨先说的,祖母已经离世了,当时再也没忍住大哭了起来,之后去了殡仪馆旁边的饭店,我父亲和我认识的一些叔叔都在饭桌前坐着,我坐到座位上边吃着饭边难过。

这件事过了快半个月我才缓过来,但每次晚上想起祖母还是很难受,很伤心,即便现在也是。当我想起来我之前最开始去外地上学前给祖母和祖父一起拍了张照片,但是我翻遍了手机和硬盘却始终找不到那两张照片了,可能是那会我觉得亲人离去对我来说还是件很遥远的事,没有放心上就清理掉了,到现在我却再也找不到了,虽然祖母的样貌在我的脑海里一直存在,但是缺少了物质上的记忆,我感觉没有一点把握,真的害怕以后忘掉祖母的样子,害怕想不起来。

写这篇文章的目的也是想告诉正在读这篇文章的你,趁现在自己的亲人都还健在,多用相机记录一些自己亲人的照片,它不仅是张张照片,更是一份回忆,不要觉得亲人离去这件事离自己很远,不要等到失去以后再想挽回,那样得到的只有悔恨。

[] == false 和 !![] == true 解析

==是相等操作符,先转换再比较;===是全等操作符,仅比较不转换。

[] == false 解析

右侧布尔值很简单,直接转换成 0

[] 不是基本数据类型,它是对象,所以需要调用 valueOf 方法(Array.prototype.valueOf() ,但是 Array 没有实现 valueOf 方法,所以根据原型链,最终调用的是 Object.prototype.valueOf):

[].valueOf():得到的仍然是 [] ,继续调用 toString 方法(Array.prototype.toString()):

[].toString():得到""

""作为基本数据类型直接调用 Number("") 得到 0

所以最终结果是 true


!![] == true

!!== 的优先级更高,所以先看 !![]

![] 得到 false (操作数是对象的话逻辑非返回 false),然后再取非,得到 true

很明显,true == true 得到的结果是 true

npm、yarn、pnpm 各自区别

npm logo
npm logo

npm

npm是围绕着语义版本控制的思想而设计的,给定一个版本号:主版本号.次版本号.补丁版本号, 以下这三种情况需要增加相应的版本号:

主版本号: 当API发生改变,并与之前的版本不兼容的时候
次版本号: 当增加了功能,但是向后兼容的时候
补丁版本号: 当做了向后兼容的缺陷修复的时候
npm使用一个名为 package.json 的文件,用户可以通过 npm install --save 命令把项目里所有的依赖项保存在这个文件里。

例如,运行 npm install --save lodash 会将以下几行添加到 package.json 文件中。

"dependencies": {
    "lodash": "^4.17.4"
}

扁平的 node_modules 结构

为了将嵌套的依赖尽量打平,避免过深的依赖树和包冗余,npm v3 将子依赖「提升」,采用扁平的 node_modules 结构,子依赖会尽量平铺安装在主依赖项所在的目录中。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

可以看到 A 的子依赖的 B@1.0 不再放在 A 的 node_modules 下了,而是与 A 同层级。

而 C 依赖的 B@2.0 因为版本号原因还是嵌套在 C 的 node_modules 下。

这样不会造成大量包的重复安装,依赖的层级也不会太深,解决了依赖地狱问题,但也形成了新的问题。

幽灵依赖 Phantom dependencies

幽灵依赖是指在 package.json 中未定义的依赖,但项目中依然可以正确地被引用到。

比如上方的示例其实我们只安装了 A 和 C:

{
  "dependencies": {
    "A": "^1.0.0",
    "C": "^1.0.0"
  }
}

由于 B 在安装时被提升到了和 A 同样的层级,所以在项目中引用 B 还是能正常工作的。

幽灵依赖是由依赖的声明丢失造成的,如果某天某个版本的 A 依赖不再依赖 B 或者 B 的版本发生了变化,那么就会造成依赖缺失或兼容性问题。

不确定性 Non-Determinism

不确定性是指:同样的 package.json 文件,install 依赖后可能不会得到同样的 node_modules 目录结构。

还是之前的例子,A 依赖 B@1.0,C 依赖 B@2.0,依赖安装后究竟应该提升 B 的 1.0 还是 2.0。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
└── node_modules
└── B@2.0.0

node_modules
├── A@1.0.0
│ └── node_modules
│ └── B@1.0.0
├── B@2.0.0
└── C@1.0.0

取决于用户的安装顺序。

如果有 package.json 变更,本地需要删除 node_modules 重新 install,否则可能会导致生产环境与开发环境 node_modules 结构不同,代码无法正常运行。

依赖分身 Doppelgangers

假设继续再安装依赖 B@1.0 的 D 模块和依赖 @B2.0 的 E 模块,此时:

A 和 D 依赖 B@1.0
C 和 E 依赖 B@2.0
以下是提升 B@1.0 的 node_modules 结构:

node_modules
├── A@1.0.0
├── B@1.0.0
├── D@1.0.0
├── C@1.0.0
│ └── node_modules
│ └── B@2.0.0
└── E@1.0.0
└── node_modules
└── B@2.0.0

可以看到 B@2.0 会被安装两次,实际上无论提升 B@1.0 还是 B@2.0,都会存在重复版本的 B 被安装,这两个重复安装的 B 就叫 doppelgangers。

而且虽然看起来模块 C 和 E 都依赖 B@2.0,但其实引用的不是同一个 B,假设 B 在导出之前做了一些缓存或者副作用,那么使用者的项目就会因此而出错。


yarn logo

yarn

2016 年,yarn 发布,yarn 也采用扁平化 node_modules 结构。它的出现是为了解决 npm v3 几个最为迫在眉睫的问题:依赖安装速度慢,不确定性。

提升安装速度

在 npm 中安装依赖时,安装任务是串行的,会按包顺序逐个执行安装,这意味着它会等待一个包完全安装,然后再继续下一个。

为了加快包安装速度,yarn 采用了并行操作,在性能上有显著的提高。而且在缓存机制上,yarn 会将每个包缓存在磁盘上,在下一次安装这个包时,可以脱离网络实现从磁盘离线安装。

lockfile 解决不确定性

yarn 更大的贡献是发明了 yarn.lock

在依赖安装时,会根据 package.josn 生成一份 yarn.lock 文件。

lockfile 里记录了依赖,以及依赖的子依赖,依赖的版本,获取地址与验证模块完整性的 hash。

即使是不同的安装顺序,相同的依赖关系在任何的环境和容器中,都能得到稳定的 node_modules 目录结构,保证了依赖安装的确定性。

所以 yarn 在出现时被定义为快速、安全、可靠的依赖管理。而 npm 在一年后的 v5 才发布了 package-lock.json

从我搜集到的情况来看,yarn 一开始的主要目标是解决上一节中描述的由于语义版本控制而导致的 npm 安装的不确定性问题。虽然可以使用 npm shrinkwrap 来实现可预测的依赖关系树,但它并不是默认选项,而是取决于所有的开发人员知道并且启用这个选项。

Yarn 采取了不同的做法。每个 yarn 安装都会生成一个类似于 npm-shrinkwrap.json yarn.lock 文件,而且它是默认创建的。除了常规信息之外,yarn.lock 文件还包含要安装的内容的校验和,以确保使用的库的版本相同。


pnpm logo

pnpm

pnpm(performant npm),在 2017 年正式发布,定义为快速的,节省磁盘空间的包管理工具,开创了一套新的依赖管理机制,成为了包管理的后起之秀。

内容寻址存储 CAS

与依赖提升和扁平化的 node_modules 不同,pnpm 引入了另一套依赖管理策略:内容寻址存储。

该策略会将包安装在系统的全局 store 中,依赖的每个版本只会在系统中安装一次。

在引用项目 node_modules 的依赖时,会通过硬链接与符号链接在全局 store 中找到这个文件。为了实现此过程,node_modules 下会多出 .pnpm 目录,而且是非扁平化结构。

  • 硬链接 Hard link:硬链接可以理解为源文件的副本,项目里安装的其实是副本,它使得用户可以通过路径引用查找到全局 store 中的源文件,而且这个副本根本不占任何空间。同时,pnpm 会在全局 store 里存储硬链接,不同的项目可以从全局 store 寻找到同一个依赖,大大地节省了磁盘空间。
  • 符号链接 Symbolic link:也叫软连接,可以理解为快捷方式,pnpm 可以通过它找到对应磁盘目录下的依赖地址。

还是使用上面 A,B,C 模块的示例,使用 pnpm 安装依赖后 node_modules 结构如下:

node_modules
├── .pnpm
│   ├── A@1.0.0
│   │   └── node_modules
│   │       ├── A => <store>/A@1.0.0
│   │       └── B => ../../B@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@1.0.0
│   ├── B@2.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@2.0.0
│   └── C@1.0.0
│       └── node_modules
│           ├── C => <store>/C@1.0.0
│           └── B => ../../B@2.0.0
│
├── A => .pnpm/A@1.0.0/node_modules/A
└── C => .pnpm/C@1.0.0/node_modules/C

<store>/xxx 开头的路径是硬链接,指向全局 store 中安装的依赖。

其余的是符号链接,指向依赖的快捷方式。

未来可期

这套全新的机制设计地十分巧妙,不仅兼容 node 的依赖解析,同时也解决了:

  1. 幽灵依赖问题:只有直接依赖会平铺在 node_modules 下,子依赖不会被提升,不会产生幽灵依赖。
  2. 依赖分身问题:相同的依赖只会在全局 store 中安装一次。项目中的都是源文件的副本,几乎不占用任何空间,没有了依赖分身。

同时,由于链接的优势,pnpm 的安装速度在大多数场景都比 npm 和 yarn 快 2 倍,节省的磁盘空间也更多。

但也存在一些弊端:

  1. 由于 pnpm 创建的 node_modules 依赖软链接,因此在不支持软链接的环境中,无法使用 pnpm,比如 Electron 应用。
  2. 因为依赖源文件是安装在 store 中,调试依赖或 patch-package 给依赖打补丁也不太方便,可能会影响其他项目。

引用

Leecason – 知乎专栏

钱曙光 – 一文看懂npm、yarn、pnpm之间的区别 – CSDN