@modern-js/main-doc 0.0.0-next-1686023023547 → 0.0.0-next-1686044917772

package/docs/en/guides/topic-detail/changesets/release.mdx

@@ -0,0 +1,229 @@
+---
+sidebar_position: 3
+---
+
+# Publishing Version
+
+When releasing a version, we need to upgrade the version of the corresponding packages based on the changeset generated during development, and run the publish command to publish them to NPM.
+
+## Steps
+
+:::info
+The following example commands are all using pnpm. If you need to use other package management tools, please replace them as needed.
+
+:::
+
+### Npm Module
+
+#### Run the bump command in the root directory
+
+```bash
+pnpm run bump
+```
+
+![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-module-bump.png)
+
+When running this command, changesets will automatically perform the following operations:
+
+- Delete all changeset files under the `.changesets` directory.
+
+- Upgrade the package version based on the changeset information.
+
+- Write changelog information to the `CHANGELOG.md` file in the root directory. The file will be automatically created if it does not exist.
+
+#### Confirm and submit the current changes
+
+```bash
+git add .
+git commit -m "release: bump package"
+```
+
+#### Run the release command in the root directory to publish the package to NPM
+
+```bash
+pnpm run release
+```
+
+![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-module-release.png)
+
+#### Push the tag to the remote repository
+
+```bash
+git push --follow-tags
+```
+
+### Monorepo
+
+#### Run the bmp command in the root directory
+
+```bash
+pnpm run bump
+```
+
+![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-monorepo-bump.png)
+
+When running this command, changesets will automatically perform the following operations:
+
+- Delete all changeset files under the `.changesets` directory.
+
+- Upgrade the version of the relevant packages based on the changeset information. In addition to the packages written in the changeset, changesets will also analyze the dependency graph of all packages in the Monorepo during running. If is required, the version will be automatically upgraded accordingly.
+
+- Write changelog to the `CHANGELOG.md` file in the directory of the package that needs to be upgraded. The file will be automatically created if it does not exist.
+
+#### Confirm and submit the current changes
+
+:::info
+Make sure that the automatically upgraded version meet the expected requirements. If you need to understand the version upgrade strategy, please refer to [Version Upgrade Strategy](/guides/topic-detail/changesets/release#version-upgrade-strategy).
+:::
+
+```bash
+git add .
+git commit -m "release: bump package"
+```
+
+#### Run the release command in the root directory to publish the package to NPM
+
+```bash
+pnpm run release
+```
+
+When running this command, it will sequentially determine whether the versions of all packages in the Monorepo exist on NPM. If they do not exist, the `publish` command will be run to publish them.
+
+:::warning
+When the dependencies between packages in the Monorepo are declared using workspace, do not directly run `npm publish` to publish the package in the corresponding subdirectory of the package. Use the `release` command instead. When publishing, the workspace declaration will be automatically removed to ensure that the NPM package is available after publishing.
+:::
+
+#### Push the tag to the remote repository
+
+```bash
+git push --follow-tags
+```
+
+## Parameters
+
+### Parameters for the `bump` command
+
+- `--snapshot`: Generates a timestamp-based version.
+
+```bash
+pnpm run bump --snapshot canary
+```
+
+After running, the corresponding upgraded version will become `0.0.0-canary-20220622092823`, and `canary` is the tag configured for snapshot. If not configured, it will directly generate the form of `0.0.0-20220622092823`.
+
+This parameter is mainly used to publish temporary test versions for testing and does not require code submission.
+
+- `--ignore`: Manually ignore some packages during publishing.
+
+For example, if you need to ignore the `module-2` package for this release:
+
+```bash
+pnpm run bump --ignore module-2
+```
+
+After running the command, the update of the `module-2` package will be ignored. Note that if there are packages that depend on `module-2`, the corresponding packages also need to be added to the `ignore` parameter, otherwise the `bump` command will fail.
+
+The usage for adding multiple packages is as follows:
+
+```bash
+pnpm run bump --ignore module-2 --ignore module-3
+```
+
+### Parameters for the `release` command
+
+- `--otp`: Uses `npm token` to publish the package.
+
+```bash
+pnpm run relese --otp <token>
+```
+
+- `--tag`: Uses a specific tag for publishing, and `latest` is used by default.
+
+```bash
+pnpm run release --tag <tag>
+```
+
+- `--ignore-scripts`: Ignores npm scripts during publishing.
+
+When running the `publish` command, npm will automatically trigger many commands, such as `prepare` and `prepublish`. Using this parameter can ignore the running of these commands. This parameter is only supported in Monorepo using pnpm.
+
+```bash
+pnpm run release --ignore-scripts
+```
+
+- `--no-git-checks`: Ignores checking the current branch during publishing.
+
+By default, when running the `release` command, it will automatically check whether the current branch is a release branch, whether there are uncommitted changes, etc. Using this parameter can ignore git-related checks.
+
+```bash
+pnpm run release --no-git-checks
+```
+
+## Version Upgrade Strategy
+
+### dependencies or devDependencies
+
+- Only upgrade the patch version of the package itself for patch version
+
+For example, the following scenario exists:
+
+There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `dependencies` of `module-2`.
+
+The current changeset is the patch version upgrade of `module-1`.
+
+After running the `bump` command, only the patch version of `module-1` will be upgraded.
+
+- Upgrade the major or minor version of the package itself for major/minor version upgrades, and upgrade the patch version of the dependent packages
+
+For example, the following scenario exists:
+
+There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `dependencies` of `module-2`.
+
+The current changeset is the minor version upgrade of `module-1`.
+
+After running the `bump` command, `module-1` will upgrade the `minor` version, and `module-2` will upgrade the `patch` version number.
+
+### peerDependencies
+
+- Upgrade the patch version of the package itself and the dependent package for patch version dependencies
+
+For example, the following scenario exists:
+
+There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`.
+
+The current changeset is the patch version upgrade of `module-1`.
+
+After running the `bump` command, both `module-1` and `module-2` will upgrade the patch version.
+
+- Upgrade the major version of the dependent package for major/minor version upgrades of the package itself
+
+For example, the following scenario exists:
+
+There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`.
+
+The current changeset is the minor version upgrade of `module-1`.
+
+After running the bump command, `module-1` will upgrade the `minor` version, and `module-2` will upgrade the `major` version number.
+
+- Modify the upgrade strategy for peerDependencies
+
+The upgrade strategy of `peerDependencies` can be modified by configuring `onlyUpdatePeerDependentsWhenOutOfRange`. When only the declared version type range is exceeded, the corresponding `peerDependencies` will be upgraded.
+
+```json
+{
+  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
+    "onlyUpdatePeerDependentsWhenOutOfRange": true
+  },
+  ...
+}
+```
+
+For example, the following scenario exists:
+
+There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` exists in the `peerDependencies` of `module-2`, and the version of `module-1` is declared using `^`.
+
+The current changeset is the patch or minor version upgrade of `module-1`.
+
+After running the `bump` command, only the version of `module-1` will be upgraded.
+
+Note that if the package version is in the `0.x.x` range, upgrading the `minor` version is also beyond the declared version type range.

package/docs/zh/community/blog/v2-release-note.mdx

@@ -71,7 +71,7 @@ sidebar_position: 97
 
 <div style={{ textAlign: 'center', fontStyle: 'italic' }}>Rspack Logo</div>
 
-相较于 Webpack，Rspack 的构建性能有明显提升，除了 Rust 带来的语言优势，这也来自于它的并行架构和增量编译等特性。经过 benchmark 验证，**Rspack 可以给 Modern.js 项目带来 5 ～ 10 倍编译性能的提升。**
+相较于 webpack，Rspack 的构建性能有明显提升，除了 Rust 带来的语言优势，这也来自于它的并行架构和增量编译等特性。经过 benchmark 验证，**Rspack 可以给 Modern.js 项目带来 5 ～ 10 倍编译性能的提升。**
 
 ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/v2-release/rspack-benchmark.png)
 

package/docs/zh/components/init-app.mdx

@@ -1,9 +1,10 @@
-Modern.js 生成器会提供一个可交互的问答界面，根据结果初始化项目，按照默认的选择进行初始化：
+`@modern-js/create` 会提供一个可交互的问答界面，根据结果初始化项目，按照默认的选择进行初始化：
 
 ```bash
-? 请选择你想创建的工程类型：Web 应用
-? 请选择开发语言：TS
-? 请选择包管理工具：pnpm
+? 请选择你想创建的工程类型 Web 应用
+? 请选择开发语言 TS
+? 请选择包管理工具 pnpm
+? 请选择构建工具 webpack
 ```
 
 在生成项目后，Modern.js 会自动安装依赖、创建 git 仓库。
@@ -20,11 +21,6 @@ pnpm run lint         # 运行 ESLint 并自动修复问题
 pnpm run new          # 启用可选功能或创建项目要素
 ```
 
-:::note
-Modern.js 生成器除了在项目初始化时工作外，也能在后续研发中生成项目各种粒度的模块，并非一用即抛开。
-
-:::
-
 现在，项目结构如下：
 
 ```

package/docs/zh/configure/app/tools/swc.mdx

@@ -19,23 +19,9 @@ import SWC from '@modern-js/builder-doc/docs/zh/shared/swc.md';
 
 ## 安装
 
-首先，你需要执行 `pnpm run new` 启用 SWC 编译：
+import EnableSWC from '@modern-js/builder-doc/docs/zh/shared/enable-swc.md';
 
-```bash
-? 请选择你想要的操作 启用可选功能
-? 请选择功能名称 启用「SWC 编译」
-```
-
-执行完成后，你只需在 `modern.config.ts` 文件中注册 SWC 插件，即可启用 SWC 编译和压缩能力。
-
-```ts title="modern.config.ts"
-import appTools, { defineConfig } from '@modern-js/app-tools';
-import swcPlugin from '@modern-js/plugin-swc';
-
-export default defineConfig({
-  plugins: [appTools(), swcPlugin()],
-});
-```
+<EnableSWC />
 
 ## 配置项
 

package/docs/zh/guides/get-started/quick-start.mdx

@@ -12,9 +12,9 @@ import Prerequisites from "@site-docs/components/prerequisites"
 
 ## 安装
 
-Modern.js 提供了 `@modern-js/create` 生成器来创建项目，不要全局安装，使用 `npx` 按需运行。
+Modern.js 提供了 `@modern-js/create` 工具来创建项目，不要全局安装，使用 `npx` 按需运行。
 
-可以使用已有的空目录来创建项目：
+可以在已有的空目录来创建项目：
 
 ```bash
 mkdir myapp && cd myapp
@@ -41,9 +41,9 @@ import DebugApp from "@site-docs/components/debug-app"
 
 ## 使用配置
 
-通过生成器创建的 Modern.js 项目中，存在 `modern.config.ts` 文件。
+通过 `@modern-js/create` 创建的 Modern.js 项目中，会默认生成 `modern.config.ts` 文件。
 
-可以通过配置文件来开启功能，或覆盖 Modern.js 的默认行为。例如添加如下配置，开启 SSR：
+可以通过该配置文件修改配置，覆盖 Modern.js 的默认行为。例如添加如下配置，开启 SSR：
 
 ```ts title="modern.config.ts"
 import appTools, { defineConfig } from '@modern-js/app-tools';
@@ -51,7 +51,6 @@ import appTools, { defineConfig } from '@modern-js/app-tools';
 export default defineConfig({
   runtime: {
     router: true,
-    state: true,
   },
   server: {
     ssr: true,
@@ -93,14 +92,12 @@ info    File sizes after production build:
 构建产物默认生成到 `dist/`，目录结构如下：
 
 ```
-.
-├── asset-manifest.json
+dist
 ├── html
-│   └── main
-├── loader-routes
-│   └── main
+│   └── main
 ├── modern.config.json
 ├── route.json
+├── routes-manifest.json
 └── static
     ├── css
     └── js

package/docs/zh/guides/get-started/upgrade.mdx

@@ -16,7 +16,7 @@ $ pnpm run upgrade
 
 > modern upgrade
 
-[INFO] [项目类型]: 应用
+[INFO] [项目类型]: Web 应用
 [INFO] [Modern.js 最新版本]: 2.0.0
 [INFO] 已更新 Modern.js 依赖至最新版本!
 ```

package/docs/zh/guides/topic-detail/changesets/add.mdx

@@ -2,9 +2,9 @@
 sidebar_position: 2
 ---
 
-# 添加一个 changeset
+# 添加 Changesets
 
-当我们开发完成一个功能时，需要添加一个 changeset 用于声明当前功能，用于后续版本发布。
+当我们开发完成时，需要添加一个 changeset 声明当前变更，用于后续版本发布。
 
 ## 信息
 
@@ -14,7 +14,7 @@ sidebar_position: 2
 
 - 本次变更需要升级的版本号类型，类型符合 [semver](https://semver.org/) 规范。
 
-- 本次变更的 Changelog 信息。
+- 本次变更的 changelog 信息。
 
 ## 步骤
 
@@ -25,17 +25,17 @@ sidebar_position: 2
 
 ### 模块工程方案
 
-#### 在根目录执行以下命令：
+#### 在根目录执行 change 命令
 
 ```bash
 pnpm run change
 ```
 
-#### 选择本次变更需要升级的版本号类型，点击回车：
+#### 选择本次变更需要升级的版本号类型
 
 ![选择版本类型](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-select-version.png)
 
-#### 填入 Changelog 信息，并点击两次回车：
+#### 填入 changelog 信息，并点击两次回车：
 
 ![写入变更信息](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-input-changelog.png)
 
@@ -55,13 +55,13 @@ feat: test module solution changeset
 
 我们假设 monorepo 中存在三个模块包，分别为 `module-1`，`module-2`，`module-3`。
 
-#### 在根目录执行以下命令：
+#### 在根目录执行 change 命令
 
 ```bash
 pnpm run change
 ```
 
-#### 选择本次需要升级的包列表：
+#### 选择本次需要升级的包列表
 
 Changesets 会根据当前代码变更(`git diff Head...baseBranch`)，将 Monorepo 中的 package 分为两类，`changed packages` 和 `unchanged packages`，方便用户进行选择。
 
@@ -69,11 +69,13 @@ Changesets 会根据当前代码变更(`git diff Head...baseBranch`)，将 Monor
 
 ![选择升级包](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-select-packages.png)
 
-#### 分别选择不同版本类型对应的包，changeset 会询问 `major` 和 `minor` 类型，如果存在包未选择这两种类型，将会默认使用 `patch` 类型：
+#### 分别选择不同版本类型对应的包
+
+changeset 会询问 `major` 和 `minor` 类型，如果存在包未选择这两种类型，将会默认使用 `patch` 类型。
 
 ![选择升级包版本类型](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-auto-select-patch.png)
 
-#### 填入 Changelog 信息，并点击两次回车：
+#### 填入 changelog 信息
 
 ![写入变更信息](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-input-changelog-monorepo.png)
 
@@ -94,10 +96,10 @@ feat: test-changeset
 
 change 命令支持以下参数：
 
-- `--empty` 添加一个空的 changeset。
+- `--empty`： 添加一个空的 changeset。
 
 ```bash
-pnpm run change -- --empty
+pnpm run change --empty
 ```
 
 执行完成后，将在项目的 `.changeset` 目录创建空的 changeset 文件，文件内容如下：
@@ -107,7 +109,7 @@ pnpm run change -- --empty
 ---
 ```
 
-- `--open` 使用该参数时，在填写 Changelog 步骤会打开系统默认编辑器进行填写。
+- `--open`： 使用该参数时，在填写 changelog 步骤会打开系统默认编辑器进行填写。
 
 ## 注意事项
 

package/docs/zh/guides/topic-detail/changesets/changelog.mdx

@@ -2,15 +2,15 @@
 sidebar_position: 6
 ---
 
-# 自定义 Changelog 生成
+# 自定义 changelog 生成
 
-Changesets 默认会使用 `@changesets/cli/changelog` 生成 Changelog 信息，如果默认的 Changelog 信息不能满足需求，可以自定义 Changelog 的生成。
+Changesets 默认会使用 `@changesets/cli/changelog` 生成 Changelog 信息，如果默认的 changelog 信息不能满足需求，可以自定义 changelog 的生成。
 
-## 自定义 Changlog 内容
+## 自定义 changelog 内容
 
-Changelog 信息主要包含以下两种信息：
+changelog 信息主要包含以下两种信息：
 
-- changeset 中写入的 Changelog 信息。
+- changeset 中写入的 changelog 信息。
 
 - 本次版本升级关联包的版本变更信息。
 
@@ -41,7 +41,7 @@ export type Changeset = {
 
 #### 返回值
 
-Changelog 内容。
+changelog 内容。
 
 #### 默认实现
 
@@ -91,7 +91,7 @@ type DependenciesUpdated = ModCompWithPackage[];
 
 #### 返回值
 
-Changelog 内容。
+changelog 内容。
 
 #### 默认实现
 
@@ -128,11 +128,11 @@ async function getDependencyReleaseLine(changesets, dependenciesUpdated) {
 
 ## 配置
 
-Changesets 配置文件中 `changelog` 字段，该字段用于标记 Changelog 信息的获取途径。
+Changesets 配置文件中 `changelog` 字段用于标记 changelog 信息的获取途径。
 
-该配置可以为字符串，直接声明获取 Changelog 信息模块的模块名称或者路径。
+该配置可以为字符串，直接声明获取 changelog 信息模块的模块名称或者路径。
 
-该配置还支持配置数组，数组中第一个元素为获取 Changelog 信息模块的模块名称或者路径，第二个元素为传入对应函数的参数值，会作为 `getReleaseLine` 和 `getDependencyReleaseLine` 函数的第三个参数传入。
+该配置还支持配置数组，数组中第一个元素为获取 changelog 信息模块的模块名称或者路径，第二个元素为传入对应函数的参数值，会作为 `getReleaseLine` 和 `getDependencyReleaseLine` 函数的第三个参数传入。
 
 ### 配置相对路径
 
@@ -162,9 +162,9 @@ module.exports = {
 
 ### 使用模块工程方案
 
-自定义 Changelog 还可以使用模块工程方案进行管理，提供通用方案。
+自定义 changelog 还可以使用模块工程方案进行管理，提供通用方案。
 
-#### 使用 `npx @modern-js/create@latest` 创建模块工程方案。
+#### 使用 `npx @modern-js/create@latest` 创建模块工程方案
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -173,7 +173,7 @@ module.exports = {
 ? 请选择包管理工具：pnpm
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getReleaseLine() {}
@@ -181,11 +181,11 @@ export async function getReleaseLine() {}
 export async function getDependencyReleaseLine() {}
 ```
 
-#### 将模块发布到 NPM。
+#### 将模块发布到 NPM
 
-#### 在目标仓库根目录安装对应模块，例如 `custom-changelog`。
+#### 在目标仓库根目录安装对应模块，例如 `custom-changelog`
 
-#### 配置 changeset 的 changelog 配置为包名称。
+#### 配置 changeset 的 changelog 配置为包名称
 
 ```json title=".changesets/config.json"
 {
@@ -198,7 +198,7 @@ export async function getDependencyReleaseLine() {}
 
 如果你当前仓库为 Monorepo 工程方案，可以直接使用模块子项目进行管理。
 
-#### 执行 `pnpm run new` 创建模块子项目。
+#### 执行 `pnpm run new` 创建模块子项目
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -207,7 +207,7 @@ export async function getDependencyReleaseLine() {}
 ? 请选择开发语言：TS
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getReleaseLine() {}
@@ -215,7 +215,7 @@ export async function getReleaseLine() {}
 export async function getDependencyReleaseLine() {}
 ```
 
-#### 在 Monorepo 根目录添加子项目模块依赖，例如 `custom-changelog`。
+#### 在 Monorepo 根目录添加子项目模块依赖，例如 `custom-changelog`
 
 ```json title="package.json"
 {
@@ -226,7 +226,7 @@ export async function getDependencyReleaseLine() {}
 }
 ```
 
-#### 配置 changeset 的 changelog 配置为包名称。
+#### 配置 changeset 的 changelog 配置为包名称
 
 ```json title=".changesets/config.json"
 {

package/docs/zh/guides/topic-detail/changesets/commit.mdx

@@ -118,7 +118,7 @@ type ReleasePlan = {
 
 - options
 
-配置 commit 时的配置信息。
+配置 commit 时的其他参数。
 
 > commit 配置为数组时，第二个参数支持传入默认的配置信息，会对应的使用该参数传递。
 
@@ -169,7 +169,7 @@ Changesets 配置文件中 `commit` 字段，该字段用于标记是否需要
 
 commit 配置如果为相对路径为 `.changesets` 目录下的相对路径。
 
-例如创建 .changeset/my-commit-config.js 文件，定义如下内容：
+例如创建 `.changeset/my-commit-config.js` 文件，定义如下内容：
 
 ```js title=".changeset/my-commit-config.js"
 async function getAddMessage(changeset, options) {}
@@ -195,9 +195,7 @@ commit 配置为 ./my-commit-config.js 即可:
 
 自定义 commit 还可以使用模块工程方案进行管理，提供通用方案。
 
-自定义 Changelog 还可以使用模块工程方案进行管理，提供通用方案。
-
-#### 使用 `npx @modern-js/create@latest` 创建模块工程方案。
+#### 使用 `npx @modern-js/create@latest` 创建模块工程方案
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -206,7 +204,7 @@ commit 配置为 ./my-commit-config.js 即可:
 ? 请选择包管理工具：pnpm
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getAddMessage() {}
@@ -214,15 +212,15 @@ export async function getAddMessage() {}
 export async function getVersionMessage() {}
 ```
 
-#### 将模块发布到 NPM。
+#### 将模块发布到 NPM
 
-#### 在目标仓库根目录安装对应模块，例如 custom-commit。
+#### 在目标仓库根目录安装对应模块，例如 `custom-commit`
 
-#### 配置 changeset 的 commit 配置为包名称。
+#### 配置 changeset 的 commit 配置为包名称
 
 ```json title="package.json"
 {
-  "changelog": "custom-commit",
+  "commit": "custom-commit",
    ...
 }
 ```
@@ -231,7 +229,7 @@ export async function getVersionMessage() {}
 
 如果你当前仓库为 Monorepo 工程方案，可以直接使用模块子项目进行管理。
 
-#### 执行 `pnpm run new` 创建模块子项目。
+#### 执行 `pnpm run new` 创建模块子项目
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -240,7 +238,7 @@ export async function getVersionMessage() {}
 ? 请选择开发语言：TS
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getAddMessage() {}
@@ -248,7 +246,7 @@ export async function getAddMessage() {}
 export async function getVersionMessage() {}
 ```
 
-#### 在 Monorepo 根目录添加子项目模块依赖，例如 custom-commit。
+#### 在 Monorepo 根目录添加子项目模块依赖，例如 `custom-commit`
 
 ```json title="package.json"
 {
@@ -259,7 +257,7 @@ export async function getVersionMessage() {}
 }
 ```
 
-#### 配置 changeset 的 commit 配置为包名称。
+#### 配置 changeset 的 commit 配置为包名称
 
 ```json title=".changesets/config.json"
 {