源码共读,第39期——如何发布一个 npm 库,自动化管理版本号、生成 changelog、tag 等

214 阅读4分钟

前言

本文参加了由公众号@若川视野 发起的每周源码共读活动,点击了解详情一起参与

本篇源码共读第39期|源码共读,第39期——如何发布一个 npm 库,自动化管理版本号、生成 changelog、tag 等,点击了解详情

准备

首先,什么是CI(CI-Continuous integration,持续集成)/CD(CD-continuous deployment,持续部署)?

以下是我百度的:

CI/CD是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。

CI/CD的核心概念是持续集成、持续交付和持续部署。

具体来说,CI/CD可让持续自动化和持续监控贯穿于应用的整个生命周期(从集成和测试阶段,到交付和部署)。这些关联的事务统称为“CI/CD管道”,由开发和运维团队协同支持。

鄙人的理解是:

将项目开发过程中重复的劳动用机器替代,将程序员的精力/时间解放出来,更好的专注于业务等创造性(搬不同形状无法批量生产的砖)的工作

那么发布这个步骤,每一次也是重复的,既然是重复的,那便可以考虑用机器替代,操作越简单越好

miniprogram-ci

miniprogram-ci 文档

上传

const ci = require('miniprogram-ci')

;(async () => {

const project = new ci.Project({

appid: 'wxsomeappid',

type: 'miniProgram',

projectPath: 'the/project/path',

privateKeyPath: 'the/path/to/privatekey',

ignores: ['node_modules/**/*'],

})

const uploadResult = await ci.upload({

project,

version: '1.1.1',

desc: 'hello',

setting: {

es6: true,

},

onProgressUpdate: console.log,

})

console.log(uploadResult)

})()

预览

const ci = require('miniprogram-ci')

;(async () => {

const project = new ci.Project({

appid: 'wxsomeappid',

type: 'miniProgram',

projectPath: 'the/project/path',

privateKeyPath: 'the/path/to/privatekey',

ignores: ['node_modules/**/*'],

})

const previewResult = await ci.preview({

project,

desc: 'hello', // 此备注将显示在“小程序助手”开发版列表中

setting: {

es6: true,

},

qrcodeFormat: 'image',

qrcodeOutputDest: '/path/to/qrcode/file/destination.jpg',

onProgressUpdate: console.log,

// pagePath: 'pages/index/index', // 预览页面

// searchQuery: 'a=1&b=2', // 预览参数 [注意!]这里的`&`字符在命令行中应写成转义字符`\&`

})

console.log(previewResult)

})()

上面的代码看着是挺简单的,操作起来也挺简单,但一定要注意setting配置,和自己项目里的setting设置一致,否则就打包不成功,本人代码复制粘贴后,操作了半小时不成功,百思不得其解(明明复制的是一样的,没有改),后来发现是setting设置问题

release-it 自动提升版本、打 tag、生成 changelog 等

首先release-it能干什么?

  1. 我们先正常提交我们自己的代码,需求或bug以及其他
  2. 自动根据上一个版本标签(Tag)与最新历史进行对比并产出日志
  3. conventional-changelog将变更写入到CHANGELOG.md
  4. 解析日志内容更新package.json的版本号
  5. 提交内容变化并打上版本标签

release-it 官网仓库

操作步骤

npm init release-it
//选择 .release-it.json 用下面的配置,复制粘贴到 .release-it.json 中。
//再安装 changelog 插件
npm i @release-it/conventional-changelog -D
{
    "github": {
        "release": false
    },
    "git": {
        "commitMessage": "release: v${version}"
    },
    "npm": {
        "publish": false
    },
    "hooks": {
        "after:bump": "echo 更新版本成功"
    },
    "plugins": {
        "@release-it/conventional-changelog": {
            "preset": "angular",
            "infile": "CHANGELOG.md"
        }
    }
}

本人看见npm init这个命令的时候,非常疑惑,难道不先install一下的吗?群里问了一下大佬,大佬回复:执行了这个命令就不用npm install了。本人继续疑惑,不install后面咋用呢。结果命令执行完后,发现这个命令的最后执行了 npm install release-it --save-dev命令,本人卒~

逼逼啥,早点动手不就知道了

理论上来说,执行完npm init release-it 命令后应该会生成一个.release-it.json文件,但本人的电脑有点问题(本人也没找到这个问题的原因,放过它吧,问题只要放过,就是没有问题),.release-it.json文件未生成,所以手动创建,创建完成后,执行命令,运行成功,舒爽~

release-it自动化管理版本号,便到这里。

接下来是发布npm包的发布流程:

参考文章是:图文结合简单易学的npm 包的发布流程

文章图文结合,通俗易懂(反正眼睛看懂了,手有没有懂,还没试

在npm发布流程教程里,我最大的收获,则是nrm这个库,之前设置镜像,都是百度命令和地址,然后修改,现在不需要了,直接nrm切换就行了,命令简单容易记。真是没想到还有人专门为了管理npm镜像开发了一个库(原谅我的浅薄,我是真第一次知道这个库),切换镜像的那一点点不适,竟然也有人来想办法解决。平时的工作(CTRL C/V)中,还是要多一双发现的眼睛啊