npm包发布流程 ​

npm 包可以发布的程度是，本地通过 npm link的方式调试的没有问题了，就发布，不是一直发布npm包版本，有问题再反复改，这点需要注意

需要学习调试，见 npm包调试

操作步骤 ​

1. 添加私有源

npm i nrm -g

# 添加万顺的私有npm 包源
nrm add wanshun http://172.25.66.6:4873/

nrm use wanshun

2. 对包进行 build， 打包

npm run build

打包以后，先把改动的内容进行提交，在执行下面的操作

也就是要有 git add 跟 git commit 动作

3. 更新包的版本号 package.json 中的 version 字段

npm run release

会自动更新版本号，自动生成 changelog 自动打 tag

# 将本地tag推动到远端 gitlab仓库
git push --follow-tags

4. 发布包到私有源

npm 官方仓库有 登录流程，我们自己的没有，要格外注意， 确认打包后的产物没有问题，再发布

npm publish

版本号升级 ​

升级 vue-plugin采用 standard-version 这个包进行操作

npm run release

会执行 standard-version 这个包， 这个包会根据 git 的提交记录，自动生成版本号，然后更新 package.json 中的 version 字段， 然后 git commit 并 push 到远程仓库， 最后发布到 npm 仓库

版本号基础操作 ​

下面使用 npm 自带的命令进行版本号升级

npm version major  // 更新主版本号 ， +1 ，z.y.z 中的z

npm version minor // 更新z.y.z 中的 y

npm version patch // 更新z.y.z 中的 z

版本号遵循， x.y.z这种格式

详细讲解：

npm version patch  // 1.0.0 会更新为 1.0.1

会做如下操作

• 自动更新 package.json中 x.y.z 中的 z版本号， 并形成一条 git log 日志
• 会自动打一个tag, tag需要手动单独推送到远端仓库才可以，不然远端仓库是没有tag的

git tag

npm version patch 并不会对 x.y.z 中 z 的大小有限制，也就是说，执行100次， 则 z 就自动累加100次， 不会出现自动进位到 y 这个

npm version minor

不管之前 x.y.z 中 z这个位置的版本号是多少，只要执行过 npm version minor ， 就会将 y 位置 +1， 将 z位置 设置为0

例如

v1.0.100  当前

执行
npm version minor

会变成
v1.1.0

npm version major

一般不要更新主版本号， 这种属于 break change， 有破坏性更新

理解上面的 minor 和 patch 的行为， major 也是类似的效果

发布公开测试版-beta版本 ​

npm version prerelease --preid=beta

一般是 某个npm包的内容修改的差不多了，经过项目的验证，没有什么问题，可以先发布一个 beta 版本， 在项目上使用， 没有什么问题了，再发布最小版本（patch）

从 v1.1.0 升级成 v1.1.1-beta.0

多次执行 npm version prerelease --preid=beta 会一直升级 beta.1, beta.2 等

standard-version ​

主要跟 git commit 的 message有关联

示例说明：

package.json

{
  "scripts": {
    "release": "standard-version"
  }
}

提交一个 commit

git commit -m 'fix: 添加了一个 .gitignore'

执行脚本

npx standard-version

或者

npm run release

执行的日志效果

PS D:\测试数据\test-1> npm run release

> test-1@1.1.1 release D:\测试数据\test-1
> standard-version

√ bumping version in package.json from 1.1.1 to 1.1.2
√ bumping version in package-lock.json from 1.1.1 to 1.1.2
√ outputting changes to CHANGELOG.md
√ committing package-lock.json and package.json and CHANGELOG.md
√ tagging release v1.1.2
i Run `git push --follow-tags origin master && npm publish` to publish

• 版本号从 1.1.1 升级到 1.1.2 (自动的)
• lock文件也升级
• 自动生成 changelog.md 日志
• 提交变动的3个文件 package-lock.json package.json CHANGELOG.md , 因为上面的2个动作，确实修改了这3个文件
• 生成一个本地的tag, 根据 升级的 package.json中的 version 打了一个tag v1.1.2
• 现在提示我们，需要把本地的tag 推送到远程gitlab仓库， 然后执行 npm publish 命令，发布npm包

# 查看刚才生成的tag
git tag

# 发布 npm 包到 npm仓库/npm 私服仓库
npm publish

git commit 的message类型 ​

基于约定式， 约定的类型如下， 为了工程化/统一化/规范化要求， 认为限定了如下内容，然后通过工具去验证 我们的message是否合格，合格则可以提交到代码仓库

参见@commitlint/config-conventional 包里面的说明

提交说明包含了下面的结构化元素，以向类库使用者表明其意图：

• fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
• feat: 类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
• BREAKING CHANGE: 在脚注中包含 BREAKING CHANGE: 或 <类型>(范围) 后面有一个 ! 的提交，表示引入了破坏性 API 变更（这和语义化版本中的 MAJOR 相对应）。 破坏性变更可以是任意 类型 提交的一部分。
• 除 fix: 和 feat: 之外，也可以使用其它提交 类型 ，例如 @commitlint/config-conventional（基于 Angular 约定）中推荐的 build:、chore:、 ci:、docs:、style:、refactor:、perf:、test:，等等。
  • build: 用于修改项目构建系统，例如修改依赖库、外部接口或者升级 Node 版本等；
  • chore: 用于对非业务性代码进行修改，例如修改构建流程或者工具配置等；
  • ci: 用于修改持续集成流程，例如修改 Travis、Jenkins 等工作流配置；
  • docs: 用于修改文档，例如修改 README 文件、API 文档等；
  • style: 用于修改代码的样式，例如调整缩进、空格、空行等；
  • refactor: 用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑；
  • perf: 用于优化性能，例如提升代码的性能、减少内存占用等；
  • test: 用于修改测试用例，例如添加、删除、修改代码的测试用例等。
• 脚注中除了 BREAKING CHANGE: <description> ，其它条目应该采用类似 git trailer format 这样的惯例。

其它提交类型在约定式提交规范中并没有强制限制，并且在语义化版本中没有隐式影响（除非它们包含 BREAKING CHANGE）。 可以为提交类型添加一个围在圆括号内的范围，以为其提供额外的上下文信息。例如 feat(parser): adds ability to parse arrays.。

• conventionalcommits 中文描述说明, 上面摘抄的内容

CHANGELOG.md 配置 ​

可以通过配置文件，指定哪些内容可以显示在 变更日志上，或者变更日志的格式

standard-version 会读取 项目下面的配置文件， .versionrc .versionrc.json .versionrc.js 任意一个，或者没有也行，没有的话，就是默认配置

这个配置主要是定制 changelog.md 里面格式样式

例如：

.versionrc.json

{
  "types": [
    {"type": "fix", "section": "bug修复", "hidden": false}
  ]
}

我在项目中修改一点内容，然后 git commit -m fix: 重新设置changelog的输出格式, 再执行 npm run release

上面的配置中，只配置了 fix 类型， 则我再修改点内容，使用 git commit -m feat: 测试其他的功能，使用feat，看看输出的changelog的格式, 再次生成日志， npm run release

发现输出的 changelog 是没有 feat 类型的， 说明要显示就需要配全

{
  "types": [
    {"type": "chore", "section":"Others", "hidden": false},
    {"type": "revert", "section":"Reverts", "hidden": false},
    {"type": "feat", "section": "Features", "hidden": false},
    {"type": "fix", "section": "Bug Fixes", "hidden": false},
    {"type": "improvement", "section": "Feature Improvements", "hidden": false},
    {"type": "docs", "section":"Docs", "hidden": false},
    {"type": "style", "section":"Styling", "hidden": false},
    {"type": "refactor", "section":"Code Refactoring", "hidden": false},
    {"type": "perf", "section":"Performance Improvements", "hidden": false},
    {"type": "test", "section":"Tests", "hidden": false},
    {"type": "build", "section":"Build System", "hidden": false},
    {"type": "ci", "section":"CI", "hidden":false}
  ]
}

hidden 表示是否显示， 上面没有配置的案例，则hidden 默认为true， 不显示， section 是可以任意调整我们的内容的， 比如改成有图标的效果+文字也可以

更详细的说明，参见 conventional-changelog-config-spec

案例 ​

我们看看 vue的 changelog

git commit -m "fix(yes-ccc): 测试一下加粗效果"

指定生成一个 beta版本 ​

测试版

npx standard-version --prerelease beta

通过参数， 指定生成一个beta版本

指定生成 alpha 版本 ​

预发布版本

npx standard-version --prerelease alpha

生成 rc 版本 ​

最终测试版本

npx standard-version --prerelease rc

撤销发布版本 ​

不小心点了 npm publish, 导致把包发布到了 npm 仓库， 需要撤销

npm unpublish vue-plugin@1.0.0

撤销指定的包的指定版本

参考链接 ​

• 简谈软件版本周期 | Alpha、Beta、RC、Stable版本之间的区别
• standard-version github 生成标准的changelog日志
• semver - 官网 版本号讲解
• conventional-changelog-config-spec github 配置 changelog 格式
• conventionalcommits 官网 约定式提交