原创专栏

　　居玉皓

　　于2015年加入去哪儿网，目前在平台事业部前端架构组，主要从事前端基础框架和工具的开发。热爱开源社区，积极参与开发和维护活跃的开源项目，喜欢钻研新技术和分享自己的见解。

　　在目前 Java 开发领域中，比较知名的模块管理器有 npm、bower、 component，以及一周前由 Facebook 公司推出的 Yarn。尽管在眼下 2016 年，npm 逐渐有一种被 Java 开发社区钦定的趋势，却还远未达到尽善尽美的地步。本文将会介绍使用 npm 管理模块时可能会遇到的问题，以及探讨刚刚出现在我们视野中的 Yarn 能带来哪些改变，是否能帮助我们更好地管理 Java 模块。

　　1. left-pad 事件

　　相信很多人还记得今年 3 月份在 Java 圈闹得沸沸扬扬的 left-pad 事件。一个名为 Azer Koçulu 的程序员因为对 npm 公司不满，将他发布在 npm 上的所有模块进行了 unpublish 操作。其中就包括一个叫 left-pad 的模块，它为很多知名的模块如 React、Babel、Ember 所依赖。当 left-pad 被移除后，这些模块均无法正常工作。从而导致了使用了它们的无以计数的项目也因此构建失败。

　　事件之后，Babel 等模块进行了紧急修复，将对它的依赖移除。又过了几天，npm 公司公开道歉，并改变了他们的 unpublish 策略。所有模块在发布 24 小时之后不再允许 unpublish，移除只能通过 npm 官方，同时要保证所要移除的模块没有被别人所依赖，以防止类似 left-pad 的事件再次发生。

　　2. npm install 可靠吗

　　npm 公司这次对于 unpublish 策略的修改，避免了在构建时依赖模块的丢失，然而这次暴露出来的问题却使人们开始质疑 npm install 这一构建过程的可靠性。其中仍然存在一个不可忽视的问题，就是模块内引用的其它模块仍然不可控。

　　譬如说现在某个项目依赖了模块 A, 我们当然可以为它指定一个唯一的版本。然而 A 所依赖的其它模块版本使用的是 npm semver 规则（semantic version，npm 模块依赖默认遵循的规则）。它并不严格规定版本，而是选择符合当前 semver 规则的最新版本进行安装。

　　一个简单的例子：假如模块 A 中依赖了 B，并且在 A 的 package.json 中指定 B 的 semver 为 ~1.2.3，那么所有形式为 1.2.x 的版本都是符合规则的。当模块 B 更新了一个 1.2.x 的小版本后，项目在下次构建中就会获取到它。

　　semver 这样设计的初衷是使模块的开发者可以将 bugfix 等微小的改动能更便捷地到达使用方。但它的负面影响却是使每次 npm install 构建过程之间，项目内的模块内容随时可能发生改变。我们没法确定在每个模块内部，每一次小版本更新时究竟是加入了 bugfix，还是改变了 API，亦或是注入了恶意代码。因此 left-pad 事件仍然可能出现。

　　3. Shrinkwrap - 使模块不可变

　　由之前的讨论可以看出，为了保证构建的可靠性，需要将 Java 模块的版本固定下来，不允许在开发者不知情的情况下发生改变，这样才能使每次构建的结果保持一致。其实在 npm 中利用 shrinkwrap 我们是可以做到这一点的。在项目中执行 npm shrinkwrap ，会根据当前 node_moduels 中已存在模块的版本依赖信息生成 npm-shrinkwrap.json，当进行下一次构建时，会按照该文件中的版本信息从源上获取，而不再使用 package.json 中的 semver 规则。shrinkwrap 文件的结构类似以下这种形式：

　　利用 shrinkwrap 我们可以保证构建的一致性，但是在实际使用中仍然存在一些问题。在较低版本的 npm 中，当我们执行模块的添加、更新、删除操作时，shrinkwrap.json 并不会自动同步，仍然需要手动执行 npm shrinkwrap，这无疑复杂了工作流程。假如某个项目成员忘记了手动同步，就会导致最终构建结果与预期不一致。另外 shrinkwrap 作为 npm 中一个非默认的构建模式，让每个人接受和使用仍需要一定的学习成本。

　　目前 npm 社区中并没有一个完备的工具能帮助我们自动生成和同步 shrinkwrap。Facebook 的 Sebastian McKenzie、James Kyle 等几名工程师曾经尝试过开发一个管理 shrinkwrap 的插件，然而由于种种原因效果并不理想。最终他们认为与其艰难地改进 npm 的基础设施，不如直接推倒重来，于是之后有了我们现在看到的Yarn.

　　4. Yarn - 自动锁定版本

　　Yarn 是 Facebook 公司在 2016 年 10 月 11 日开源的模块管理器，它宣称比 npm 更快、更安全、更可靠。Yarn 并不重头建立一个新的 Java 模块仓库，而只是替代 npm 客户端来管理原有的 node_modules 中的模块，并弥补 npm 的缺陷。鉴于国情的原因，为了使用 Yarn ，我们需要把它的源指向国内，比如采用 cnpm 的源：

　　在 Yarn 中，锁定版本号成为了一个默认行为。Yarn 会在项目中自动生成一个名为 yarn.lock 的文件，它与 npm shrinkwrap 的内容形式很相近，并且会随着模块的更新自动同步。这解决了在 npm 中我们需要手动添加和同步 shrinkwrap 的问题。当然，在项目构建时我们仍然可以选择不使用 yarn.lock。加上 –no-lockfile 参数，模块的安装依旧会遵循 semver 规则。

　　5. 性能与体验

　　npm 的速度慢一直是一个为人诟病的问题。在一个复杂的项目中执行 npm install，我们通常可以去倒杯咖啡，然后回来再看它是否完成了，对于漫长的等待已经习以为常。Yarn 为了解决速度问题，在构建时采用并行操作，优化了请求队列，更高效地利用当前的网络资源，同时 yarn.lock 也无形中减少了解析 semver 与获取模块最新版本的时间。另外，所有从源上获取的模块都会进行离线缓存，从而极大地加快重复构建的过程。

　　我在本地试验了一个 React Native 的项目，同样使用 cnpm 源，不采用任何缓存。npm 的构建花了 2 分 20 秒，而 Yarn 仅仅用了 1 分 16 秒就完成了，减少了近一半的时间。而利用 Yarn 的离线缓存机制进行重新构建，这次只用了 20 秒。Twitter 上一个名为 @timdorr 的开发者说，使用 yarn 可以让他每周多出 30 分钟开发时间。或许使用了 Yarn 之后，不会再有构建一次还有时间去倒咖啡的情形了。

　　在用户体验方面，运行 npm install 命令总是令我感到提心吊胆，因为它在构建过程中给出的信息实在不够清晰，我并不知道它究竟在做什么（即使加了 --verbose）。有时它会停在某一步不再继续运行，或是突然抛出一个难以追踪的错误。而 Yarn 的构建提示明显更加友好：

Yarn 会给出构建过程共有多少步，以及现在进行到了哪里。

如果抛出警告，Yarn 会告诉你该模块的依赖关系（相比 npm 中只告诉你某个模块有问题，然而当项目并没有对其直接依赖，就很难进行定位了）。

在每个 Yarn 命令执行完成后，总会打出用时多少。

最后，Yarn 中有很多可爱的 emoji 表情。

　　执行 yarn install

　　6. 小结

　　总的来说，npm 仍然是当前最火热的 Java 模块管理器，但其历史包袱或许阻碍了它为开发者提供更好服务的脚步。 Yarn 仅仅开源了一周，就已经在 Github 上被提了一大堆 issue，star 数也远远超过 npm，可见人们对于一个更好的模块管理器已经期待已久。现在已经能看到在保证构建的可靠性与提升开发效率方面，Yarn 正在带来积极的改变。在 Java 模块管理器的更迭演进中，Yarn 迈出了向前的一小步。

　　对以上内容有疑问或需要交流的，欢迎留言，会及时回复大家。点击阅读原文，可以查看更多信息哦

　　不关注

　　就捣蛋

　　长按上方二维码，关注“公众号”