背景
- 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
升级后问题
- 由于这个项目始于两年前，所以react版本比较滞后——react@0.14.8。然而正好是在这个版本使用yarn打包后在run的时候会报一个propType相关的error-Warning，尤其在项目跑单测的时候会被这个warning刷屏。
- 另一个问题同时也是上一个问题的根本原因，
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后项目里的子依赖在小版本上较新，虽然这在一般情况下没有问题，但在大型项目下尤其要注意！
