往NPM上发布几个库了？版本号你用对了吗？

Dear，大家好，我是“前端小鑫同学”，?长期从事前端开发，安卓开发，热衷技术，在编程路上越走越远～

前言：

在Node横行的大前端环境里总是重复的在创造或者安装依赖npm仓库的依赖，很多朋友也发布过自己的npm包，或者因为一些依赖包有问题而进行升级，但是你真的了解package.json中版本号的意思吗？我们一起来学习一下。

NPM Cli中的version：

先附上官网文档的地址：https://docs.npmjs.com/cli/v7/commands/npm-version ​

文中的第一条命令就是：

npm version [<newversion>| major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>]| from-git] ​

1. 需要指定版本号的命令操作为：npm version 0.0.5；
2. 需要发布主版本的命令操作为：npm version major；
3. 需要发布次要版本的命令操作为：npm version minor；
4. 需要发布补丁版本的命令操作为：npm version patch；
5. 需要预发布的版本为加pre前缀的对应命令；

​

我们依次执行了指定版本号和从打补丁到主版本升级的命令操作，请看下图：

接着来看一下预发布的几条命令的执行，尤其是指定预发布前缀的命令，请看下图：

​

看了上面的的版本号的格式有没有找到点感觉？你是不是还在手动的修改字符串呀？顺便请看一下你的git仓库，你会发现tag都帮你打好了：

有时候你会有这样的疑问，我比较版本号做升级的时候直接用数字类型多简单，搞一个小数点就够了你这来俩？

这里推荐使用已经有的语义化版本号比较的库semver，依赖库的地址是https://www.npmjs.com/package/semver。 这个库提供了常见的用法如下：

const semver = require('semver')

semver.valid('1.2.3') // '1.2.3'
semver.valid('a.b.c') // null
semver.clean('  =v1.2.3   ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true
semver.minVersion('>=1.0.0') // '1.0.0'
semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7'

接着我们要看一下语义化版本号的一些东西：

1. 版本号的组成：主版本号.次版本号.修订号；
2. 版本号的递增规则：
   1. 不兼容API修改：主版本+1；
   2. 向下兼容功能新增：次版本号+1；
   3. 向下兼容的bug修复：修订号+1。
3. 规范说明：
   1. 项目处于初始阶段，一切都有可能被推翻，主版本号应该为0；
   2. 当项目的公共API形成后具备了可发布的能力，版本号应为1.0.0，且后续更新基于这个版本；
   3. 当我们只是做了当前版本的问题修复，应该增加修订版本号；
   4. 当我们做了可向下兼容的新功能是或公共API被标记弃用是，应该增加次版本号且修订号归零；
   5. 当我们做了无法向下兼容的修改加入公共API时，应该增加主版本号且次版本号及修订号归零；
   6. 有时候会提前发布一些版本来提供使用，那就需要增加预发版本，标识版本并非稳定，可能存在不兼容。
4. 当功能准备废弃掉要怎么办？
   1. 更新文件让使用者感知这个改变；
   2. 将功能弃用在适当的次版本发布；
   3. 在新的主版本中正式废弃并移除，并在一个次版本中保留被弃用的功能便于使用者迁移；

更多详细的内容XMD阅读一下文档：https://semver.org/lang/zh-CN/

总结就是两点：

1. 我们在做一些对外公布使用的模块时请参照语义化版本号的规则来执行，便于使用者找到自己想要的版本；
2. 在我们要通过版本升级来解决一些问题的时候，我们可以知道那个版本可以放心大胆用，哪些版本要注意兼容。