tccpc / blog Goto Github PK

背景

• npm 安装时存在不确定性
• npm 安装速度慢

两年的时间发展，项目已经非常复杂了，引入的依赖也非常多，npm由于是围绕着语义版本控制（semver）的**而设计的，所以在安装时存在不确定性。

给定一个版本号：主版本号.次版本号.补丁版本号， 以下这三种情况需要增加相应的版本号:

• 主版本号： 当API发生改变，并与之前的版本不兼容的时候
• 次版本号： 当增加了功能，但是向后兼容的时候
• 补丁版本号： 当做了向后兼容的缺陷修复的时候

依赖版本的控制存在不确定性。为了解决这个问题，npm提供了shrinkwrap命令。此命令将生成一个npm-shrinkwrap.json文件，为所有库和所有嵌套依赖的库记录确切的版本。
然而，即使存在npm-shrinkwrap.json这个文件，npm也只会锁定库的版本，而不是库的内容。即便npm现在也能阻止用户多次重复发布库的同一版本，但是npm管理员仍然具有强制更新某些库的权力。
所以npm还是存在安装不确定性。而yarn的设计会默认创建yarn.lock，yarn.lock文件还包含要安装的内容的校验和，以确保使用的库的版本相同。

另一个问题项目依赖变多，npm速度明显变慢，yarn的速度提升较为明显。

升级

安装

brew install yarn

重新组织node_modules 目录

yarn

升级后问题

1. 由于这个项目始于两年前，所以react版本比较滞后——[email protected]。然而正好是在这个版本使用yarn打包后在run的时候会报一个propType相关的error-Warning，尤其在项目跑单测的时候会被这个warning刷屏。

2. 另一个问题同时也是上一个问题的根本原因，yarn install 的node_modules和 npm install 的node_modules内容不同，而这个内容不同又分为两个方面一个是每个依赖的结构目录不同，另一个是个别依赖的子依赖版本不同（package.json里每个依赖使用的都是固定版本，并没有使用^）
   举个例子；
   查看同一项目下的rc-trigger（相同版本）的子依赖rc-align的版本
   npm仓库：
   
   yarn仓库：
   

可以看出两个子依赖rc-align的版本不同，这在大型项目下是非常需要注意的！

npm在安装依赖时一般会默认在package.json中对应依赖版本号前加^

• ~会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
• ^会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0

所以这个rc-trigger虽然是同一个版本，但rc-trigger的1.4.0版本在npm仓库发布时最新的rc-align版本是2.3.3，而在yarn出来时建立rc-trigger的1.4.0版本时rc-align的版本已经更新到2.3.5。
它们都满足rc-trigger1.4.0版本package.json中dependencies下rc-align的版本，如下图

2.3.3和2.3.5都符合2.x，所以升级到yarn后项目里的子依赖在小版本上较新，虽然这在一般情况下没有问题，但在大型项目下尤其要注意！