9月7日,Yarn 发布了 1.0 版本。自去年10月 facebook 公开 Yarn ,短短11个月时间,Github 上已经有超过175000个项目在使用 Yarn,每个月经过 Yarn 下载 JavaScript 包近30亿次。包括微软、Twiiter 等在内的大大小小许多公司,以及各开源社区都被 Yarn 的快速、安全、可靠所吸引。许多持续集成服务,好比 CircleCI、TravisCI 以及 AppVeyor 等都预置了 Yarn。那这一次 1.0版本的发布,Yarn 又有哪些新功能呢?git
许多大公司采用 monorepo 方法来管理代码,一些小公司和开源社区也渐渐开始使用 monorepo。这种方法解决了依赖同步问题。为了让人们更方便的采用这种模式, Yarn 增长了 Workspaces 功能。这个功能能够自动的将项目依赖的多个package.json
合并为一个,而后一次性完成安装。在根文件中也会只有一个yarn.lock
文件来跟踪这些依赖。另外, Yarn 会在全部互相依赖的 Workspace 间建立软连接。这样,最后的代码能够用于全部项目。
Facebook 和 开源社区的 Babel 项目已经在使用 Workspace 了。若是你正在用 monorepo 管理工具 - Lerna,你能够选择用 Yarn 的 Workspaces。这个 PR 是一个起步的好例子。Yarn 但愿在增长了 Workspace 以后,可以让一个大项目的各部分再也不有重复的包,使得安装更快速、轻便。github
一个多人合做且迭代迅速的项目,可能须要一个接一个的 PR 去更新依赖。这很容易致使 yarn.lock
在 merge 的时候发生冲突。有一个两个包发生冲突,解决起来还很容易,可是多了的话工做就变得繁琐而乏味了。
Yarn 的 auto-merge 功能会在出现 lockfile 冲突的时候经过 yarn install
自动解决这些冲突。json
有时候,package 会有一些紧急 BUG 修复或漏洞更新须要尽快采用。可是你的项目却没有直接使用这些依赖,而是经过许多别的依赖间接使用该 package。这种状况下,你只能等直接使用的依赖更新或者 fork 它而后再更新依赖。两种方法都不够好。Yarn 的 selective version resolution
功能针对这种状况提供了更好的解决办法。
在项目的 package.json
文件中定义一个resolutions
区域,能够在其中指定要使用的次级依赖的版本。这样能够灵活的控制间接依赖。下面的例子展现了指定 async
模块版本的状况:安全