【@changesets/cli】变更集实战教程

一、背景概述

前端目前基于Monorepo架构的npm包开发很普遍，在开发完毕后，我们需要对包进行版本号升级，并且部署，这些操作如果是手动来操作的话，很麻烦，而且容易出错。

例如有这样的场景：

-apps
-packages-core-layout-plugins

我们在发版的时候，需要手动去更改core、layout、plugins三个插件包的版本号。

并且如果要查看每个包的变更迭代的话，需要单独查看子包的git log进行查看，但是有时git log的记录不代表版本真正的迭代变更，最常见的是子包的一个特性开发，会分成多个commit去提交。

以上场景我们可以使用changeset来解决，查看：官网地址。

二、正常模式

1、安装 changesets

进入Monorepo项目根目录，执行下列命令：

# 安装 changesets
pnpm add -W -D @changesets/cli

2、初始化项目

# 初始化 changesets 文件夹
npx changeset init
#pnpm exec changeset init //pnpm的话执行pnpm exec,效果一致

执行完初始化命令后，会在工程的根目录下生成 .changeset 目录，其中的 config.json 作为默认的 changeset 的配置文件。

config.json 代码如下：

{"$schema": "https://unpkg.com/@changesets/config@3.0.0/schema.json","changelog": "@changesets/cli/changelog","commit": false,"fixed": [],"linked": [],"access": "restricted","baseBranch": "personal-wjb","updateInternalDependencies": "patch","ignore": ["docs", "micro-app", "umi3", "umi4"]
}

配置说明：

changelog:changelog 生成方式
commit: 不要让 changeset 在 publish 的时候帮我们做 git add
linked: 配置哪些包要共享版本
access: 公私有安全设定，内网建议 restricted ，开源使用 public
baseBranch: 项目主分支
updateInternalDependencies: 确保某包依赖的包发生 upgrade，该包也要发生 version upgrade 的衡量单位（量级）
ignore: 不需要变动 version 的包
___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH: 在每次 version 变动时一定无理由 patch 抬升依赖他的那些包的版本，防止陷入 major 优先的未更新问题

更多配置说明，请查看【changeset官网】

3、配置`package.json`

"changeset": "changeset",
"packages-version": "changeset version",
"publish:only": "changeset publish --registry=指定仓地址"

4、提交变更集

执行pnpm changeset，进入交互式变更集设置命令行：

在这里插入图片描述

这里需要注意的是，版本的选择一共有三种类型，分别是 patch、minor 和 major，严格遵循 semver 规范。

可以简单按照下图这么理解：

5、升级版本号

当我们开发完成一个特性需求之后，我们的.changeset目录下可能会缓存了很多的变更记录，这时候我们要准备发版，就需要进行升级版本号操作，升级完后，.changeset目录中缓存的所有UNIQUE_ID.md文件会被清空。

执行pnpm packages-version，由于上面【步骤4】选择了补丁版本（patch），所以只会升级第三位版本号，变成1.0.1。

{- "version": "1.0.0",+ "version": "1.0.1",
}

然后如果有些包不需要升级版本号的话，可以通过设置/changeset/config.json中的ignore属性进行过滤。或者直接设置待过滤包的package.json，添加private:true设置。

命令执行完成后，会在每个需要升级的包目录下，自动生成CHANGELOG.md文件，会记录当前包的所有的变更。

6、部署

执行pnpm publish:only，会自动部署到指定的npm仓。之后就可以正常使用。

设置子包中的package.json中的publishConfig.registry=npm仓，可以指定部署目标仓地址。

三、预发布模式

1、进入预发布模式

pnpm exec changeset pre enter <preid>

preid 为预发布版本标记，例如 alpha、beta 等，默认值为 next。

我们执行pnpm exec changeset pre enter next，执行成功后会在.changeset中新增pre.json文件。

//pre.json
{"mode": "pre","tag": "next","initialVersions": {"micro-app": "1.0.0","@my-package/components": "1.0.17","@my-package/hooks": "1.0.5","@my-package/utils": "1.0.3"},"changesets": []
}

2、开发

进入预发布模式后，我们可以进行正常的代码开发，和变更集提交。

我们这里添加了两个变更集，如图：

<!-- fluffy-seahorses-watch.md -->
---
"@my-package/components": patch
"@my-package/utils": patch
---修改路由

<!-- breezy-maps-listen.md -->
---
"@my-package/hooks": patch
"@my-package/utils": patch
---修改路由配置-2

3、升级版本号

执行：changeset version ，由于是在【预发布模式】，更新的版本号会加上<preid>标记。

例如：
在这里插入图片描述
预发布模式下，后续的版本号升级都会更新末尾的索引号。按照这个逻辑，下次@my-package/components更新的版本号就是1.0.18-nest.1，

如图：

更新版本号后，pre.json中的内容也会更新：

//pre.json
{"mode": "pre","tag": "next","initialVersions": {"micro-app": "1.0.0","@my-package/components": "1.0.18-next.1","@my-package/hooks": "1.0.5","@my-package/utils": "1.0.3"},"changesets": ["breezy-maps-listen","fluffy-seahorses-watch","tender-cars-taste"]
}