深入 Node 子產品的安裝和釋出

npm 是一個友善的 node 子產品分發、管理工具。我們平常會使用 <code>npm install</code> 安裝子產品，使用 <code>npm publish</code> 釋出子產品。事實上除了基本功能，這 2 個指令還有其他非常有用的特性。這篇文章會給大家介紹這些指令的一些“進階”用法。

我們先來說說版本号。npm 使用的是一種叫做 semantic version 的規範，它的規則很簡單，總結起來就是下面幾條：

使用 semver 的軟體必須定義公開、嚴謹、易于了解的 api。也就是子產品要提供功能給使用者。

版本号格式為：<code>x.y.z</code>，并且 x、y、z 均為正整數并且不斷遞增。x 表示大版本（major）、y 表示小版本（minor）、z 表示更新檔版本（patch）。

一個版本釋出後，此版本内容不能再變更，變更必須再釋出一個新版本。也就是不能覆寫釋出。

<code>0.y.z</code> 表示初始版本，這種版本下的 api 不能保證穩定，随時可能變更。

當進行了向後相容的 bug 修複時，更新檔版本 z 必須增加。

當引入了向後相容的新功能時，小版本 y 必須增加，同時 z 必須重置為 0（小版本裡面可能會包含 bug 修複）。

當引入了不相容的變更時，大版本 x 必須增加，同時 y、z 必須重置為 0（大版本裡面可能會包含小版本或者更新檔版本的改動）。

<code>x.y.z</code> 後面還可以加預釋出版本号、建構資訊，格式為：<code>x.y.z-pre_lease+build_meta</code>，比如：<code>1.0.0-alpha+20151226</code>、<code>1.0.0-beta.2+20151230</code>。

進行版本号比較時，遵循下面的規則：1）依次按數值比較 x、y、z 的值，直到第一個不同的位置；2）如果兩個版本的 x、y、z 都相等，含有 pre-release 版本号的較小；3）如果兩個版本的 x、y、z 都相等并且都含有 pre-release 版本号，要單獨比較 pre-release 版本。比如：<code>1.0.0 &lt; 2.0.0 &lt; 2.1.0 &lt; 2.1.1</code>，<code>1.0.0-alpha &lt; 1.0.0</code>，<code>1.0.0-alpha &lt; 1.0.0-alpha.1 &lt; 1.0.0-alpha.beta &lt; 1.0.0-beta &lt; 1.0.0-beta.2</code>。

在進行項目開發時，對于依賴的子產品進行管理是非常必要的。這種管理主要展現在：

如何友善的擷取項目需要使用的子產品

目前項目依賴了哪些子產品，或許還會指定子產品依賴的環境（哪些子產品是生産階段依賴的、哪些是開發階段依賴的）

子產品的哪些版本是和目前項目相容的，可以直接使用

其他成員（或者系統）如何友善的擷取所有子產品，進而能讓項目正常運作

下面我們看看 npm 是如何幫助我們解決上面這些問題的。

我們在進行項目開發時，如果需要某個功能，都會先去 npm registry 上搜一搜，看看有沒有類似的子產品可以直接複用，進而提高開發效率。擷取子產品非常簡單，我們在項目的根目錄直接執行 <code>npm install name</code> 就可以将子產品安裝在 <code>node_modules</code> 目錄下，然後直接 <code>require</code> 就可使用。

上面擷取子產品的方法是一種“臨時”起意的方式，并不能記錄我們依賴子產品的具體資訊（除非我們自己去查找）。我們安裝子產品時，可以執行 <code>npm install name --save</code>（生産階段的依賴） 或是 <code>npm install name --save-dev</code>（開發階段的依賴），來将子產品資訊儲存到項目的 <code>package.json</code> 檔案中。

執行 <code>npm install name --save</code> 來安裝子產品時，npm 會首先安裝子產品的最新版本，然後将子產品名及子產品版本号以最“保險”的表示方式寫入到 <code>package.json</code> 檔案中。

比如，我們執行 <code>npm install koa --save</code>，安裝子產品後，會更新<code>package.json</code> 檔案的 <code>dependencies</code> 字段：

項目對子產品的依賴可以使用下面的 3 種方法來表示（假設目前版本号是 1.1.0 ）：

相容子產品新釋出的更新檔版本：<code>~1.1.0</code>、<code>1.1.x</code>、<code>1.1</code>

相容子產品新釋出的小版本、更新檔版本：<code>^1.1.0</code>、<code>1.x</code>、<code>1</code>

相容子產品新釋出的大版本、小版本、更新檔版本：<code>*</code>、<code>x</code>

可以看到，npm 預設會将依賴表示為最“保險”的方式（即：擷取子產品新釋出的更新檔版本），我們也可以使用 <code>npm install koa --save-exact</code> 來精确的指定子產品版本（這種情況依賴就直接表示為：<code>"koa": "1.1.0"</code>）。

除了擷取子產品的最新版本，我們還可以精确擷取子產品的某個具體版本，如：<code>npm install [email protected] --save</code>，這種情況依賴就會表示為：<code>"koa": "~1.0.0"</code>。

子產品的依賴都被寫入了 <code>package.json</code> 檔案，其他合作者（比如：其他小夥伴、或者是部署服務）隻要進入項目的根目錄，執行 <code>npm install</code> 就可以将依賴的子產品全部安裝到 <code>node_modules</code> 目錄下。

比如下面的 <code>package.json</code>：

當我們執行 <code>npm install</code> 時，就會安裝 <code>dependencies</code> 及 <code>devdependencies</code> 字段裡列出的所有子產品。如果隻想安裝 <code>dependencies</code> 裡面列出的子產品，可以使用 <code>npm install --only=production</code>。

這裡 npm 實際安裝的子產品是根據依賴的表示來決定的：

<code>"bluebird": "~3.1.1"</code> 表示會安裝最新的更新檔版本。比如：安裝 3.1.2、3.1.3 等，但是不會安裝 3.2.0 這種小版本或者4.0.0 這種大版本（就算這些版本是最新的）。這種表示法是比較保險的，因為更新檔版本隻是 bug 修複，不會新增功能。

<code>"request-promise": "^1.0.2"</code> 表示會安裝最新的更新檔版本或者小版本。比如：安裝 1.1.0、1.1.1 等小版本，或者 1.0.3、1.0.4 等更新檔版本，但是不會安裝 2.0.0 這種大版本。而且，總是安裝版本号最大的（也就是優先安裝小版本）。這種表示法通常是保險的，小版本會增加向後相容的功能。

<code>"lodash": "*"</code> 表示安裝最新的版本（不管這個版本是大版本、小版本、還是更新檔版本）。這種表示法非常危險，如果有大版本，直接就安裝了大版本，而大版本通常是不會向後相容的，可能導緻項目功能運作異常。

對于子產品的提供者來說，每一次釋出都應該盡量遵循 semver 的規範來變更版本号，不要讓使用者困惑甚至是想罵人......

在“子產品的版本号”部分我們介紹了 semver 規範，npm 也提供了相關的指令來讓我們友善的進行版本号變更：

更新更新檔版本号：<code>npm version patch</code>

更新小版本号：<code>npm version minor</code>

更新大版本号：<code>npm version major</code>

一個比較合适的釋出流程可以是：

根據此次變更執行 <code>npm version [new version]</code> 指令（npm 會根據 <code>new version</code> 指定的類型更新 <code>package.json</code> 中的<code>version</code> 字段，然後進行一次 commit，最後打上一個該版本号的 tag）。

執行 <code>git push origin master --tags</code>，将改動同步到遠端代碼倉庫。

執行 <code>npm publish</code>，将子產品釋出到 npm 倉庫。

子產品安裝指令的最簡形式 <code>npm install name</code> 的完整版其實應該是：<code>npm install name@latest</code>。這裡的 <code>latest</code> 是子產品版本的一個 tag，會對應到子產品的一個具體版本。

我們來看一個例子：子產品 koa 在 npm registry 上的資訊如下（完整版見：http://registry.npmjs.com/koa）：

當執行 <code>npm install koa</code> 時，其實是執行 <code>npm install koa@latest</code>，而這個 <code>latest</code> 等于 <code>dist-tags.latest</code>（版本 1.1.2），最後版本 1.1.2 被安裝，同時依賴會标記為 <code>"koa": "~1.1.2"</code>。

當執行 <code>npm install koa@next</code> 時， <code>next</code> 等于 <code>dist-tags.next</code>（版本 2.0.0-alpha.3），最後版本 2.0.0-alpha.3 被安裝，同時依賴會标記為 <code>"koa": "~2.0.0-alpha.3"</code>。

子產品的維護者在進行子產品釋出時，可以指定将目前版本釋出為哪個 tag（預設是 latest）。

當執行 <code>npm publish</code> 時，會首先将目前版本釋出到 npm registry，然後更新 <code>dist-tags.latest</code> 的值為新版本。

當執行 <code>npm publish --tag=next</code> 時，會首先将目前版本釋出到 npm registry，并且更新 <code>dist-tags.next</code> 的值為新版本。這裡的 next 可以是任意有意義的命名（比如：v1.x、v2.x 等等）。

可以看出，tag 就是對子產品某一個版本的标記（類比 git 中 tag 是對某一次送出的标記），并且這個 tag 還可以随時更新為新的版本号。

能對版本打 tag，使得我們在維護多個版本時非常友善。比如，可以像 koa 的做法一樣，新開一個 next 的 tag 來提供新版本給社群試用，而不影響現在的穩定版本。等到新版本逐漸穩定後，再将其釋出為 latest 即可。

這樣看起來，釋出 node 子產品是不是很簡單？其實，我們沒有說的東西還有很多。比如下面這些問題：

每次釋出前怎麼保證子產品提供的功能沒有損壞？可以考慮接入持續內建系統，每次 push 運作單元測試，未通過不進行釋出。

版本号其實對維護者不友好，很容易改錯，有沒有什麼好方法來解決？可以考慮規範送出資訊，維護者隻是描述變更，從送出資訊中抽取變更類型然後生成正确的版本号和變更日志（比如：angular 的送出資訊規範：https://docs.google.com/document/d/1qrdfciipjsldn3el15ijygnpihorgu1_ooaqwjidu5y/edit）

這些問題要是可以自動化多好！我嘗試搜尋了下，果然有開發者在搞了。推薦大家看看這個工具：https://github.com/semantic-release/semantic-release，很好的解決了上面的問題。

但是其實最最核心的問題是維護者得養成好習慣（寫單測、規範送出資訊），不然再好的工具都白搭。我也在慢慢培養中，真是痛苦......