node.js 中的npm模塊版本管理

semver

npm 中的模塊版本都須要遵循 semver 2.0 的語義化版本規則。

版本格式：主版本號.次版本號.修訂號，版本號遞增規則以下： 主版本號：當你作了不兼容的API 修改， 次版本號：當你作了向下兼容的功能性新增， 修訂號：當你作了向下兼容的問題修正。 先行版本號及版本編譯信息能夠加到「主版本號.次版本號.修訂號」的後面，做爲延伸。

而後基於語義化的版本，咱們在選擇版本的時候就能夠對依賴進行版本的控制：

dependencies: { "express": "3.x", "debug": "*", "express-session": "~1.0.0", "connect-redis": "1.2.3" }

從例子中能夠看到，有許多種選擇版本範圍的風格，能夠在 semver in npm 上看到每個不一樣風格的做用。 而在 node.js 的模塊管理中，最經常使用到的幾種是：

• *: 任意版本
• 1.1.0: 指定版本
• ~1.1.0: >=1.1.0 && < 1.2.0
• ^1.1.0: >=1.1.0 && < 2.0.0

其中 ~ 和 ^ 兩個前綴讓人比較迷惑，簡單的來講：

• ~ 前綴表示，安裝大於指定的這個版本，而且匹配到 x.y.z 中 z 最新的版本。
• ^ 前綴在 ^0.y.z 時的表現和 ~0.y.z 是同樣的，然而 ^1.y.z 的時候，就會 匹配到 y 和 z 都是最新的版本。
• 特殊的是，當版本號爲 ^0.0.z 或者 ~0.0.z 的時候，考慮到 0.0.z 是一個不穩定版本， 因此它們都至關於 =0.0.z。

semver 的弊端

按照 semver 的規範：

1. 全部的 breaking change 都須要升級主版本號。
2. 向後兼容的新增功能能夠只升級次版本號。

可是最終在實踐過程當中，許多包沒有遵循該原則，或者是沒注意破壞了該原則，致使：

1. 新增功能帶來了 breaking change
2. 修復現有 bug 引入未知的 breaking change

由此引出了下一個話題：如何正確的選擇依賴模塊依賴範圍。

如何選擇依賴範圍

node 模塊

在編寫 node 的模塊的時候，模塊自身可能會依賴一些 dependencies, 然而咱們並不想每一次依賴的 模塊有任何小的 bug fix 的時候就要從新更新一次依賴，所以會推薦對大部分的依賴使用 ~ 前綴， 這樣能夠保證能夠享受到這些依賴模塊的 bug fix，而且不須要更新自身的版本。同時，也不會引入 一些 API 變動致使的沒法預料的錯誤。固然，若是對一些徹底信任的模塊也能夠考慮使用 ^ 前綴。

see: koa

node 項目

然而在編寫 node 的項目的時候，咱們更加但願可以追蹤到全部依賴的任何變更，由於項目也不會有 關於自身版本更新的煩惱，所以更加傾向於寫死依賴的版本，這樣若是有任何因爲更加容易追蹤 升級依賴致使的 bug。

see: koa-todo

如何選擇發佈模塊的版本

看完編寫過程當中怎麼樣選擇依賴的範圍，回過頭來看看，若是咱們須要編寫一個發佈到 npm 的模塊， 須要如何選擇發佈的模塊的版本。

1. 當剛開始開發這個模塊，它的功能和 API 都會有較大的調整的時候，能夠選擇發佈 0.0.z 版本。
2. 而當一個模塊的 API 基本已經成型，不過可能會有一些新的 API 增長的時候，能夠選擇發佈 0.y.z 版本。
3. 當一個模塊的功能基本已經徹底定下來的時候，能夠選擇發佈 x.y.z(x >= 1) 版本。當模塊發佈到 npm 以後，就意味着已經正式準備好了，因此儘可能把發佈的第一個版本定爲 1.0.0。
4. 當修復了一些小的 bug 的時候，請升級 z 的版本號，這樣可讓用戶經過 ~ 和 ^ 前綴最快速的享受你的 bug fix。
5. 當增長了新的功能的時候，能夠選擇升級 y 的版本號。
6. 當變動會影響原有接口的狀況下，起碼要升級 y 的版本號，這樣不會影響大部分依賴這個庫的用戶。
7. 當重構了模塊，從設計上就有很大不一樣的狀況下，須要升級 x 版本號。

遵循這幾條規則，這樣用戶在引入這個模塊的時候就能夠輕鬆的經過 semver 提供的驗證機制來更輕鬆的使用你的模塊。