likes
comments
collection
share

前端工程化之版本规范

作者站长头像
站长
· 阅读数 9

npm包版本

semantic versioning (语义化版本) 格式

前端工程化之版本规范

  • major

主版本，一般代表着Breaking Change，例如vue 1．x和vue 2．x、webpack 3．x和 webpack 4.x。

  • minor

此版本，一般代表着新feature的出现。

  • patch

一般不包含新功能，只是bugfix或者和功能关系不大的修改。

  • pre-release

预发行版本，一般用于正式版发行前的验证、联调和测试。和正式版本号之间用—连接alpha,beta,rc (release candidate)。

大小比较

2.3.2 > 2.2.17 > 2.2.17—beta.1 > 2.2.17—beta.0 > 2.2.17—alpha.1 > 2.2.16

版本范围

// 大于、小于、大于等于、小于等于
>、<、>=、<=

// —表示范围，边界可等
1.2.3-2.3.4 等价于 >=1.2.3 <=2.3.4 

//  x表示通配，和各种语言的通配符一样x:
1.2.x 等价于 >=1.2.0 <1.3.0 

// ~ 表示限制minor版本的升级
~1.2.3 等价于 >=1.2.3 < 1.(2+1).0 等价于 >=1.2.3 < 1.3.0 

// ^ 表示允许第二个非零的版本的升级
^1.2.3 等价于 >=1.2.3 < 2.0.0 

^0.2.3 等价于 >=0.2.3 < 0.3.0 

^0.0.3 等价于 >=0.0.3 < 0.0.4

需要注意的是^ 表示允许第二个非零的版本的升级。

为什么我们要遵守Semantic Versioning？

  • 为了让我们的版本语义和npm社区统一，让我们的npm包可以被用户正确的使用。

  • 享受社区生态带来的便利，让我们可以利用社区现有方案，更灵活地管理依赖的版本。

changelog

什么是Changelog？

Changelog是以时间为倒序的列表，记录所有版本的重大变动。

为什么要有Changelog？

为了让我们提供的库和框架的用户了解，每个版本发生了哪些改变，提供多于版本号的信息。比如commit id 和提交作者等。

前端工程化之版本规范

release-it

自动化版本管理。

  • 根据git commit自动生成版本号

  • 自动生成changelog

  • 丰富的hooks用来定制发版逻辑

  • 提供插件机制，高度可扩展

配置文件 .release-it.json

{
  "github": {
    "release": true
  },
  "git": {
    "changelog": "npx auto-changelog --stdout --commit-limit false",
    "requireCleanWorkingDir": false,
    "requireUpstream": true,
    "requireCommits": false,
    "addUntrackedFiles": false,
    // 自动提交
    "commit": true,
    // 如果实现未git commit，那么将这个字符串设置为commit msg
    "commitMessage": "release: v${version}",
    "commitArgs": "",
    // 自动打tag
    "tag": true,
    "tagName": "${version}",
    "tagAnnotation": "Release ${version}",
    "tagArgs": "",
    // 自动推送到github
    "push": true,
    "pushArgs": "--follow-tags",
    "pushRepo": "origin"
  },
  "npm": {
    // 自动发布到npm上
    "publish": true,
    "publishPath": ".",
    "access": null,
    "otp": null
  },
  "hooks": {
    "after:bump": "npx auto-changelog -p"
  },
  "plugins": {
    "@release-it/conventional-changelog": {
      "preset": "angular",
      "infile": "CHANGELOG.md"
    }
  }
}

生成Changelog文件，需要安装@release-it/conventional-changelog插件，并在.release-i.json文件中配置。


{
  "plugins": {
    "@release-it/conventional-changelog": {
      "preset": "angular",
      "infile": "CHANGELOG.md"
    }
  }
}

前端工程化之版本规范

当我们提交代码后，release-it是如何知道更新哪个版本的呢？

它通过我们提交的commit message来确定的。这种commit message叫做angular commit规范。

这里是一个测试案例

angular commit规范

在 Angular 中，推荐使用规范化的提交信息格式，也称为“Commitizen”规范，以帮助项目成员更好地理解提交的修改和目的，进而更好地协作开发。该规范的提交信息格式如下：

<type>(<scope>): <subject>

<body>

<footer>

各个字段的含义如下：

  • type（必需）：表示代码修改的类型，可以是 feat（新功能）、fix（缺陷修复）、docs（文档）、style（格式或样式调整）、refactor（重构代码）、test（新增或修改测试）、chore（构建或工具流程）等。
  • scope（可选）：表示被修改的部分，如页面、组件、服务等。不是每个修改都需要指定 scope。
  • subject（必需）：简洁地描述了所做的更改。
  • body（可选）：更详细的描述提交的修改信息，可以包含多行。
  • footer（可选）：包含一些元信息，如与其他问题的链接、关闭的问题等。

例如：

feat(login): add remember me functionality

Add remember me checkbox to login page

Closes #123

该提交信息表明了代码修改的类型为 “新功能（feat）”，涉及的部分是“登录（login）”，描述了增加“记住我”功能，详细描述为“添加了登录页面上的记住我复选框”，并将跟踪和关闭问题 #123。

使用规范的提交信息格式可以帮助开发者清晰、精确记录每一次代码提交，更好地与团队协作，同时方便追溯修改记录和排查问题。

转载自:https://juejin.cn/post/7240248679515635771
评论
请登录