记录通过GitHub Action来自动化发布npm包
文章前言
永远把别人对你的批评记在心里,别人的表扬,就把它忘了。Hello 大家好~!我是南宫墨言QAQ
本文主要是记录自己在使用 GitHub Action
来发布npm包的过程,与各位小伙伴分享,也欢迎各位小伙伴对文中不正确的地方在评论区指出,谢谢
观看到文章最后的话,如果觉得不错,可以点个关注或者点个赞哦!感谢~❤️
文章主体
感谢各位观者的耐心观看,GitHub Action自动化发布npm包使用正片即将开始,且听南宫墨言QAQ娓娓道来
GitHub Actions
是一套提供给 GitHub
仓库的 CI/CD
工具,它轻松实现所有软件工作流程的自动化。直接从 GitHub
构建、测试和部署您的代码。按照您想要的方式进行代码审查、分支管理和问题分类。
以下文章内容,我将以maoyan-request这个仓库作为基础,给大家展示如何自动化发布npm包(版本)
CHANGELOG
所谓自动化部署,简单理解就是根据代码的变化来进行一系列操作,那么记录变更是不可或缺的,这里我们使用 @changesets/cli
开源仓库来生成 CHANGELOG.md
安装
npm i @changesets/cli
使用
- 首次使用时,我们需要在项目根目录生成一个.changeset文件夹(执行命令如下),里面包含一个配置文件和README
npm exec changeset init
包含的的文件如下:
- 迭代版本时,执行以下命令
npm exec changeset
这里会要求我们选择迭代的类型,[可以了解下npm semver版本号规范]()
patch
是小的bug修改
minjor
是不影响之前版本功能的小feature功能
major
是包含breaking change的大版本改动,比如从1.0.0 到 2.0.0
输入本次修改的信息,一路回车就行
执行完之后会在.changeset文件夹下生成一个随机名字的md文件,里面包含您刚才提交的信息
- 生成版本号
npm exec changeset version
该命令会读取您刚才生成的changeset文件,写入CHANGELOG.md
, 并把项目的package.json
文件中的版本号按照您选择的类型进行升级。
package.json
{
"version": "0.1.0",
"license": "MIT",
"main": "dist/index.js",
"typings": "dist/index.d.ts",
"files": [
"dist",
"src"
],
"engines": {
"node": ">=10"
},
"scripts": {
"start": "tsdx watch",
"build": "tsdx build",
"test": "tsdx test",
"lint": "tsdx lint",
"prepare": "tsdx build",
"size": "size-limit",
"analyze": "size-limit --why",
"changeset": "changeset",
"version": "changeset version && pnpm install"
},
"husky": {
"hooks": {
"pre-commit": "tsdx lint"
}
},
"prettier": {
"printWidth": 80,
"semi": true,
"singleQuote": true,
"trailingComma": "es5"
},
"name": "maoyan-request",
"author": "nangongmoyan",
"module": "dist/maoyan-request.esm.js",
"size-limit": [
{
"path": "dist/maoyan-request.cjs.production.min.js",
"limit": "10 KB"
},
{
"path": "dist/maoyan-request.esm.js",
"limit": "10 KB"
}
],
"devDependencies": {
"@size-limit/preset-small-lib": "^9.0.0",
"husky": "^8.0.3",
"size-limit": "^9.0.0",
"tsdx": "^0.14.1",
"tslib": "^2.6.2",
"typescript": "^5.2.2"
},
"dependencies": {
"@changesets/cli": "^2.26.2",
"axios": "^1.2.0-alpha.1"
}
}
最后将代码推到 GitHub
仓库,接下来我们将配置 NPM_TOKEN
和创建编写 GitHub Action
自动化脚本
NPM_TOKEN
NPM_TOKEN
相当于打通 GitHub
和 npm
之间的通道,在编写脚本之前我们需要先生成 NPM_TOKEN
生成token
- 进入npm首页 在登录后点击头像,点击
Access Tokens
- 点击
Generate New Token
,选择Classic Token
就可以了
给token起个名称,并选择权限
生成的token记得复制,关闭页面后就看不到了
生成的token记得复制,关闭页面后就看不到了
生成的token记得复制,关闭页面后就看不到了
- GitHub中配置token
回到GitHub中该项目的仓库,首先点击Settings,然后选择左侧Secrets andvariables下的Actions,再点击New repository secret, 最后将 NPM_TOKEN
填入Name, 将复制的token填入Secret
输入secret信息,点击add secret
生成secret成功
GitHub Action自动化脚本
创建 .yml脚本
- 进入项目地址,首先选择
Actions
,然后点击New workflow
,再选择Publish Node.js Package
类型,最后来修改npm-publish.yml
脚本,在修改完成后点击右上角绿色按钮Commit changes
,会出现一个弹窗
新建 workflow
修改npm-publish.yml
脚本
Commit changes
在项目目录下就会生成对应的脚本文件
最终脚本内容如下:
# This workflow will run tests using node and then publish a package to GitHub Packages when a release is created
# For more information see: https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages
name: Node.js Package
# 触发时机,在 main 分支 push 操作触发
on:
push:
branches:
- main
# 默认shell
defaults:
run:
shell: bash
# 任务,定义个changelog 的任务
jobs:
changelog:
# name:Changelog PR or Release
# 这里判断仓库owner是否是我自己,为了避免别人 fork 仓库触发,请自行修改
if: ${{ github.repository_owner == 'nangongmoyan' }}
runs-on: ubuntu-latest
steps:
# name: 当前 step 的名字
- name: Checkout # 获取分支的代码和提交记录
uses: actions/checkout@v3
# 设置 Node
- name: Setup Node.js # 设置 Node.js 的环境
uses: actions/setup-node@v3
with:
node-version: "lts/*"
# cache: 'npm'
# 安装依赖
- name: Install dependencies
run: npm install
# 打包
- name: Build Packages
run: npm run build
# 这一步是最重要的。使用changesets/action自动创建 PR 或者发布
- name: Create Release Pull Request or Publish
id: changesets
uses: changesets/action@v1
with:
# 执行更新版本和发布的命令
version: npm run version
publish: npm exec changeset publish
commit: '[ci] release'
title: '[ci] release'
env:
# 这里需要几个 Token 变量
# GITHUB_TOKEN 是 CI 里自带的默认 token
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# NPM_TOKEN 需要稍后在 npm 网站生成。
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
为了方便,我们在项目的package.json
中添加几个脚本:
// package.json
{
"scripts": {
"changeset": "changeset",
"version": "changeset version && npm install"
}
}
可以在Github
的Actions下看到该脚本的执行过程
之后可以在npm上面看到该包
最后演示下完整工作流程
一般我们在开发维护项目的时候是不建议在main
(主分支)上直接进行修改,所以在新增功能或修复bug的时候切一个新的分支来完成功能开发
新建分支feat/coming-soon分支
git checkout -b feat/coming-soon
在filmApi下增加即将上映的api
/**
* 即将上映
* @param vo
* @returns
*/
comingSoonFilm: async(vo: Film.ComingSoon.Request) => {
const rlt = await apiRequest.get('/mmdb/movie/home/list/rt/order/coming.json', {
params: vo
})
return rlt
}
运行生成changeset文件
npm exec changeset
生成 changeset
文件之后,注意不用执行再 version
命令了,把 changeset
文件和我们的代码修改一并提交。
发起PR
CI 发起 release PR
PR 合并进 main 分支之后,就触发了我们前面设置的 action。
点击 Actions 查看,我们刚才的提交,触发了一个叫做 Release 的工作流。你可以点开查看,它会在 CI 环境里执行我们预设好的脚本
我们的脚本就是,如果检测到提交携带有 changeset
信息,就会自动发起一个叫做 [ci] release
的 PR。这个 PR 中,CI 自动帮我们做好了 CHANGELOG
的生成,版本号的升级
当你点击 merge,合并到 main 分支之后,它就会自动地发布版本,同时发布到 npm 仓库和 GitHub release
未合并期间,所有携带有 changeset
的提交都会更新这个 PR
发布
点击 merge
发布!恭喜你完成了整个流程
过一会就能看到 GitHub release
和 npm
包都发布成功了
npm上的包已经更新了,yeah
总结
看到这里的小伙伴可能会说,你这一顿操作下来不还是半自动化嘛,这点我无法否认,但是你不得不承认这是一套规范的开源协作流程,在多人协作的项目时,不正是通过这样的方式来发布项目的嘛
- 仓库的贡献者,修改代码,生成
changeset
CI
自动归结,生成CHANGELOG
并 PR- 仓库的维护者,点击
merge
自动发布
就问你这个流程是不是改变以往手动修改版本发布的方式,如果你认可的话,不妨动手试试看,嘻嘻
参考文章
南宫墨言QAQ在此非常感谢以下几位优秀的博主提供他们关于浏览器缓存的优秀文章,感谢~❤️
结尾营业
看官都看到这了,如果觉得不错,可不可以不吝啬你的小手手帮忙点个关注或者点个赞
转载自:https://juejin.cn/post/7291135035217248290