原創(chuàng)專欄

　　居玉皓

　　于2015年加入去哪兒網(wǎng)，目前在平臺(tái)事業(yè)部前端架構(gòu)組，主要從事前端基礎(chǔ)框架和工具的開發(fā)。熱愛開源社區(qū)，積極參與開發(fā)和維護(hù)活躍的開源項(xiàng)目，喜歡鉆研新技術(shù)和分享自己的見解。

　　在目前 Java 開發(fā)領(lǐng)域中，比較知名的模塊管理器有 npm、bower、 component，以及一周前由 Facebook 公司推出的 Yarn。盡管在眼下 2016 年，npm 逐漸有一種被 Java 開發(fā)社區(qū)欽定的趨勢(shì)，卻還遠(yuǎn)未達(dá)到盡善盡美的地步。本文將會(huì)介紹使用 npm 管理模塊時(shí)可能會(huì)遇到的問題，以及探討剛剛出現(xiàn)在我們視野中的 Yarn 能帶來哪些改變，是否能幫助我們更好地管理 Java 模塊。

　　1. left-pad 事件

　　相信很多人還記得今年 3 月份在 Java 圈鬧得沸沸揚(yáng)揚(yáng)的 left-pad 事件。一個(gè)名為 Azer Ko?ulu 的程序員因?yàn)閷?duì) npm 公司不滿，將他發(fā)布在 npm 上的所有模塊進(jìn)行了 unpublish 操作。其中就包括一個(gè)叫 left-pad 的模塊，它為很多知名的模塊如 React、Babel、Ember 所依賴。當(dāng) left-pad 被移除后，這些模塊均無法正常工作。從而導(dǎo)致了使用了它們的無以計(jì)數(shù)的項(xiàng)目也因此構(gòu)建失敗。

　　事件之后，Babel 等模塊進(jìn)行了緊急修復(fù)，將對(duì)它的依賴移除。又過了幾天，npm 公司公開道歉，并改變了他們的 unpublish 策略。所有模塊在發(fā)布 24 小時(shí)之后不再允許 unpublish，移除只能通過 npm 官方，同時(shí)要保證所要移除的模塊沒有被別人所依賴，以防止類似 left-pad 的事件再次發(fā)生。

　　2. npm install 可靠嗎

　　npm 公司這次對(duì)于 unpublish 策略的修改，避免了在構(gòu)建時(shí)依賴模塊的丟失，然而這次暴露出來的問題卻使人們開始質(zhì)疑 npm install 這一構(gòu)建過程的可靠性。其中仍然存在一個(gè)不可忽視的問題，就是模塊內(nèi)引用的其它模塊仍然不可控。

　　譬如說現(xiàn)在某個(gè)項(xiàng)目依賴了模塊 A, 我們當(dāng)然可以為它指定一個(gè)唯一的版本。然而 A 所依賴的其它模塊版本使用的是 npm semver 規(guī)則（semantic version，npm 模塊依賴默認(rèn)遵循的規(guī)則）。它并不嚴(yán)格規(guī)定版本，而是選擇符合當(dāng)前 semver 規(guī)則的最新版本進(jìn)行安裝。

　　一個(gè)簡單的例子：假如模塊 A 中依賴了 B，并且在 A 的 package.json 中指定 B 的 semver 為 ~1.2.3，那么所有形式為 1.2.x 的版本都是符合規(guī)則的。當(dāng)模塊 B 更新了一個(gè) 1.2.x 的小版本后，項(xiàng)目在下次構(gòu)建中就會(huì)獲取到它。

　　semver 這樣設(shè)計(jì)的初衷是使模塊的開發(fā)者可以將 bugfix 等微小的改動(dòng)能更便捷地到達(dá)使用方。但它的負(fù)面影響卻是使每次 npm install 構(gòu)建過程之間，項(xiàng)目內(nèi)的模塊內(nèi)容隨時(shí)可能發(fā)生改變。我們沒法確定在每個(gè)模塊內(nèi)部，每一次小版本更新時(shí)究竟是加入了 bugfix，還是改變了 API，亦或是注入了惡意代碼。因此 left-pad 事件仍然可能出現(xiàn)。

　　3. Shrinkwrap - 使模塊不可變

　　由之前的討論可以看出，為了保證構(gòu)建的可靠性，需要將 Java 模塊的版本固定下來，不允許在開發(fā)者不知情的情況下發(fā)生改變，這樣才能使每次構(gòu)建的結(jié)果保持一致。其實(shí)在 npm 中利用 shrinkwrap 我們是可以做到這一點(diǎn)的。在項(xiàng)目中執(zhí)行 npm shrinkwrap ，會(huì)根據(jù)當(dāng)前 node_moduels 中已存在模塊的版本依賴信息生成 npm-shrinkwrap.json，當(dāng)進(jìn)行下一次構(gòu)建時(shí)，會(huì)按照該文件中的版本信息從源上獲取，而不再使用 package.json 中的 semver 規(guī)則。shrinkwrap 文件的結(jié)構(gòu)類似以下這種形式：

　　利用 shrinkwrap 我們可以保證構(gòu)建的一致性，但是在實(shí)際使用中仍然存在一些問題。在較低版本的 npm 中，當(dāng)我們執(zhí)行模塊的添加、更新、刪除操作時(shí)，shrinkwrap.json 并不會(huì)自動(dòng)同步，仍然需要手動(dòng)執(zhí)行 npm shrinkwrap，這無疑復(fù)雜了工作流程。假如某個(gè)項(xiàng)目成員忘記了手動(dòng)同步，就會(huì)導(dǎo)致最終構(gòu)建結(jié)果與預(yù)期不一致。另外 shrinkwrap 作為 npm 中一個(gè)非默認(rèn)的構(gòu)建模式，讓每個(gè)人接受和使用仍需要一定的學(xué)習(xí)成本。

　　目前 npm 社區(qū)中并沒有一個(gè)完備的工具能幫助我們自動(dòng)生成和同步 shrinkwrap。Facebook 的 Sebastian McKenzie、James Kyle 等幾名工程師曾經(jīng)嘗試過開發(fā)一個(gè)管理 shrinkwrap 的插件，然而由于種種原因效果并不理想。最終他們認(rèn)為與其艱難地改進(jìn) npm 的基礎(chǔ)設(shè)施，不如直接推倒重來，于是之后有了我們現(xiàn)在看到的Yarn.

　　4. Yarn - 自動(dòng)鎖定版本

　　Yarn 是 Facebook 公司在 2016 年 10 月 11 日開源的模塊管理器，它宣稱比 npm 更快、更安全、更可靠。Yarn 并不重頭建立一個(gè)新的 Java 模塊倉庫，而只是替代 npm 客戶端來管理原有的 node_modules 中的模塊，并彌補(bǔ) npm 的缺陷。鑒于國情的原因，為了使用 Yarn ，我們需要把它的源指向國內(nèi)，比如采用 cnpm 的源：

　　在 Yarn 中，鎖定版本號(hào)成為了一個(gè)默認(rèn)行為。Yarn 會(huì)在項(xiàng)目中自動(dòng)生成一個(gè)名為 yarn.lock 的文件，它與 npm shrinkwrap 的內(nèi)容形式很相近，并且會(huì)隨著模塊的更新自動(dòng)同步。這解決了在 npm 中我們需要手動(dòng)添加和同步 shrinkwrap 的問題。當(dāng)然，在項(xiàng)目構(gòu)建時(shí)我們?nèi)匀豢梢赃x擇不使用 yarn.lock。加上 –no-lockfile 參數(shù)，模塊的安裝依舊會(huì)遵循 semver 規(guī)則。

　　5. 性能與體驗(yàn)

　　npm 的速度慢一直是一個(gè)為人詬病的問題。在一個(gè)復(fù)雜的項(xiàng)目中執(zhí)行 npm install，我們通常可以去倒杯咖啡，然后回來再看它是否完成了，對(duì)于漫長的等待已經(jīng)習(xí)以為常。Yarn 為了解決速度問題，在構(gòu)建時(shí)采用并行操作，優(yōu)化了請(qǐng)求隊(duì)列，更高效地利用當(dāng)前的網(wǎng)絡(luò)資源，同時(shí) yarn.lock 也無形中減少了解析 semver 與獲取模塊最新版本的時(shí)間。另外，所有從源上獲取的模塊都會(huì)進(jìn)行離線緩存，從而極大地加快重復(fù)構(gòu)建的過程。

　　我在本地試驗(yàn)了一個(gè) React Native 的項(xiàng)目，同樣使用 cnpm 源，不采用任何緩存。npm 的構(gòu)建花了 2 分 20 秒，而 Yarn 僅僅用了 1 分 16 秒就完成了，減少了近一半的時(shí)間。而利用 Yarn 的離線緩存機(jī)制進(jìn)行重新構(gòu)建，這次只用了 20 秒。Twitter 上一個(gè)名為 @timdorr 的開發(fā)者說，使用 yarn 可以讓他每周多出 30 分鐘開發(fā)時(shí)間?；蛟S使用了 Yarn 之后，不會(huì)再有構(gòu)建一次還有時(shí)間去倒咖啡的情形了。

　　在用戶體驗(yàn)方面，運(yùn)行 npm install 命令總是令我感到提心吊膽，因?yàn)樗跇?gòu)建過程中給出的信息實(shí)在不夠清晰，我并不知道它究竟在做什么（即使加了 --verbose）。有時(shí)它會(huì)停在某一步不再繼續(xù)運(yùn)行，或是突然拋出一個(gè)難以追蹤的錯(cuò)誤。而 Yarn 的構(gòu)建提示明顯更加友好：

Yarn 會(huì)給出構(gòu)建過程共有多少步，以及現(xiàn)在進(jìn)行到了哪里。

如果拋出警告，Yarn 會(huì)告訴你該模塊的依賴關(guān)系（相比 npm 中只告訴你某個(gè)模塊有問題，然而當(dāng)項(xiàng)目并沒有對(duì)其直接依賴，就很難進(jìn)行定位了）。

在每個(gè) Yarn 命令執(zhí)行完成后，總會(huì)打出用時(shí)多少。

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

　　執(zhí)行 yarn install

　　6. 小結(jié)

　　總的來說，npm 仍然是當(dāng)前最火熱的 Java 模塊管理器，但其歷史包袱或許阻礙了它為開發(fā)者提供更好服務(wù)的腳步。 Yarn 僅僅開源了一周，就已經(jīng)在 Github 上被提了一大堆 issue，star 數(shù)也遠(yuǎn)遠(yuǎn)超過 npm，可見人們對(duì)于一個(gè)更好的模塊管理器已經(jīng)期待已久?，F(xiàn)在已經(jīng)能看到在保證構(gòu)建的可靠性與提升開發(fā)效率方面，Yarn 正在帶來積極的改變。在 Java 模塊管理器的更迭演進(jìn)中，Yarn 邁出了向前的一小步。

　　對(duì)以上內(nèi)容有疑問或需要交流的，歡迎留言，會(huì)及時(shí)回復(fù)大家。點(diǎn)擊閱讀原文，可以查看更多信息哦

　　不關(guān)注

　　就搗蛋

　　長按上方二維碼，關(guān)注“公眾號(hào)”