依赖包的版本号匹配策略&&版本号管理策略&&使用npm管理项目版本号

忘是亡心i 2023-02-15 03:35 15阅读 0赞

### 文章目录 ###

*  依赖包的版本号匹配策略
 *  使用命令管理自己的版本号
 *  版本号策略
 *  编程式
 *  自动更新版本号

# 依赖包的版本号匹配策略 #

*  `~`会匹配最近的小版本依赖包，比如~1.2.3会匹配所有1.2.x版本，但是不包括1.3.0
 *  `^`会匹配最新的大版本依赖包，比如^1.2.3会匹配所有1.x.x的包，包括1.3.0，但是不包括2.0.0
 *  没有`~`和`^`，完全匹配指定版本号

设置默认版本号匹配规则`npm config set save-prefix ["^"|"~"|""]` 。

可以在项目`package.json`同级目录下创建`.npmrc`文件，来指定项目的版本号匹配规则`save-prefix=""`

# 使用命令管理自己的版本号 #

在现代大前端的项目中，版本号管理使用的是`npm`的命令——别跟我说，你是手动改`package.json`来更新版本号的。

在命令行敲入`npm version --help`就可以看到可以使用的命令：

*  major：主版本号
 *  minor：次版本号
 *  patch：补丁号
 *  premajor：预备主版本
 *  prepatch：预备次版本
 *  prerelease：预发布版本

我的`package.json`当前`version`为`6.0.0`，依次输入下面的命令，`package.json`的`version`会变更为提升后的版本号。

C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.0.0)
    λ npm version preminor
    v6.1.0-0
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.1.0-0)
    λ npm version minor
    v6.1.0
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.1.0)
    λ npm version prepatch
    v6.1.1-0
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.1.1-0)
    λ npm version patch
    v6.1.1
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.1.1)
    λ npm version prerelease
    v6.1.2-0
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@6.1.2-0)
    λ npm version premajor
    v7.0.0-0
    C:\Users\Administrator\Desktop\work\stage-view (master) (stage-view@7.0.0-0)
    λ npm version major
    v7.0.0

如上所示，敲入`npm version preminor`，项目的version就从6.0.0变成了6.1.0-0。

对了，项目的`git status`必须是`clear`，才能使用上述命令。

如果你的项目中包含`git`，它还会自动给你提交更新到git，`git commit -m "X.Y.Z"`，所以还可以在`npm version NEWVERSION` 后面加上`-m`参数来指定自定义的`commit message`。比如：

npm version patch -m "Upgrade to %s for reasons"

`message`中的`s%`将会被替换为版本号。

# 版本号策略 #

版本号格式：主版本号\*\*.**次版本号**.\*\*修订号；

主版本号：当你做了不兼容的 API 修改；

次版本号：当你做了向后兼容的功能性新增；

修订号：当你做了向后兼容的问题修正；

处于开发阶段的项目版本号以0.Y.Z形式表示，此阶段正在开发基础功能、公众API；

版本号只能增加，禁止下降，代码的修改必须以新版本形式更新；

如何判断发布 1.0.0 版本的时机？ 当你的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了。

万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？一旦发现自己破坏了语义化版本控制的规范，就要修正这个问题，并发行一个新的次版本号来更正这个问题并且恢复向下兼容。即使是这种情况，也不能去修改已发行的版本。

# 编程式 #

在项目代码中有时候需要判断当前版本，可以通过读取package文件获取当前版本：

import { version} from './package.json'

要判断两个版本号字符串的大小，可以使用插件 compare-versions :

compareVersions('10.1.8', '10.0.4'); // 1
    compareVersions('10.0.1', '10.0.1'); // 0

# 自动更新版本号 #

在项目目录的`.git/hooks/`目录中新建文件: `post-commit`——是的，没有后缀名。  
然后粘贴以下代码并保存文件：

#!/bin/sh
    COMMIT_MSG="$(git log --pretty=format:"%s" -1 head)"
    echo "$COMMIT_MSG" | grep  -q  "^[0-9]"
    if [ $? -ne 0 ];then
      echo $(npm version patch)
    fi

上面代码会在每次`git commit` 执行后被运行，它检查commit的message是不是版本号，如果不是，它就会执行`npm version patch`更新版本号。

[原文地址][Link 1]

[Link 1]: http://buzhundong.com/post/%E7%89%88%E6%9C%AC%E5%8F%B7%E7%AE%A1%E7%90%86%E7%AD%96%E7%95%A5-%E4%BD%BF%E7%94%A8npm%E7%AE%A1%E7%90%86%E9%A1%B9%E7%9B%AE%E7%89%88%E6%9C%AC%E5%8F%B7.html