还记得中秋节，国庆节，前端界趁机发布了Angular，Vue的新版本吗？这周Facebook悄然也发布了一个包管理工具Yarn，赶紧来看看到底是什么情况。本文由译者@旭日云中竹投稿发布。

　　正文从这开始～

　　在Java社区，工程师们分享了成百上千的代码段，我们不用自己从头编写基础组件、类库或者框架。反过来，每段代码又或许依赖于其它的代码段，而这些依赖就是通过 package managers(包管理器) 来管理的。最流行的Java包管理器就是 npm客户端了，j2直播，它可以访问在npm注册的 300,000 多个安装包。超出500万的工程师使用npm注册，每个月的下载量高达 50 亿。

　　我们成功地在Facebook用了几年的npm客户端。但随着代码库规模的扩大以及开发者人数的增加，我们碰到了连贯性，安全性 和 性能 方面的问题。在迎难而上解决一个又一个的问题后，我们着手构建一个新的方案，来帮助我们更可靠地管理我们的依赖。执行这项工作的产品名为 Yarn -- 它是一个快速、可靠、安全的、可替换的npm客户端。

　　我们很高兴地宣布与Exponent、 Google 和 Tilde 合作的 Yarn 开源版本。有了 Yarn之后, 软件工程师们仍然可以访问npm库，而且可以更快地安装npm包，并且跨机器或者在安全的离线环境下一致性地管理依赖。Yarn 使得工程师可以更加快速开发，并且信心百倍地使用分享的代码库，从而专注于更重要的事情 -- 构建新的产品和特性。

　　Facebook JS 包管理器的进化史

　　在还没包管理器的时候，JS工程师常常依赖于存储在他们项目中或者放在CDN上面的少量代码段。第一个主要的JS包管理器 npm 在Node.js被引用后不久就搭建起来了，并且迅速成为世界上最受欢迎的包管理器之一。上千个新的开源项目被建立了，工程师们也比以往分享了更多的代码。

　　很多Facebook的项目（如React），都是依赖于npm包。然而，随着内部规模的扩大，我们都遇到了这样的问题：当跨机器或用户安装依赖时，拉取依赖包消耗的时间较长，也考虑到安全性的问题，因为npm客户端会自动执行这些依赖包里面的代码。我们尝试去解决这些问题，却发现这些问题还不断地衍生出新的问题。

　　尝试操作npm客户端的规模

　　起初，按照指定的最佳实践，我们只是检入 package.json 并且要求开发者手动地执行npm install 。这足以满足软件工程师的开发需求，但在我们持续集成的环境中就崩溃了，因为处于安全性和可靠性的考虑，这种环境需要沙箱化，并且切断网络服务。

　　我们的第二个方案是检入所有进入代码库的 node_modules。这种做法虽然奏效，却使得一些原本简单的操作变得相当困难。举个例子，更新一个小版本 babel 就会生成一个80万行的commit，这对于无效的UTF8字节串、窗口的行尾退出符号，非 png-crushed 的图片等都很难处理。工程师们经常都要花上一整天的时间，才能把改动的代码合并到 node_modules中。我们掌控源代码的团队也指出：检查 node_modules 文件是对大量元数据负责任的做法。React Native 的 package.json 文件目前只是列出了68个依赖，但执行 npm install 之后，node_modules 目录下就生成了121，358个文件。

　　我们做了最后一个尝试来规划npm客户端的大小，使之可以和开发者的数量以及我们所需的代码量来协调工作。我们觉得压缩整个 node_modules 文件夹，并且把它上传到内部的CDN，这样开发者和我们持续的集成系统都可以下载，并一致地提取文件。这使得我们可以从原文件中删除成千上百个文件。但是，这样做软件开发者不仅是拉取还是构建新代码，都需要网络服务。

　　我们也必须应对 npm shrinkwrap 功能所带来的问题，因为我们通过 shrinkwrap 来锁定版本。npm-shrinkwrap.json 不是默认生成的，如果开发者忘记生成，就会导致不同步的问题。因此我们写了一个工具，来验证安装包里的文件与 node_modules 中的哪些文件相匹配。npm-shrinkwrap.json 是由大量无序字段组成的 JSON blobs ，所以改变它们就会生成庞大的、无法 review 的commits。为了缓和这个问题，我们需要额外添加一个脚本来区分所有的条目。

　　基于 semantic versioning（语义法版本控制） 原则，用npm更新一个简单的依赖, 也会相应更新许多不相关的依赖。这样使得每次改变的代码量大大增加， 而且必须重复提交 node_modules 或者上传到CDN这样的事情，这个过程对开发者来说是不理想的。

　　构建一个新的客户端

　　我们决定尝试整体地去看待这个问题，而不是在npm客户端继续修复。假如我们尝试搭建了一个新的客户端来处理遇到的这些核心问题又会怎样呢？我们伦敦工作室的 Sebastian McKenzie 已经开始hack这个想法，我们也为它的前景而兴奋。