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 提供的验证机制来更轻松的使用你的模块。