@modern-js/main-doc 0.0.0-next-1686037191101 → 0.0.0-next-1686045734613

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

@@ -2,20 +2,20 @@
 sidebar_position: 3
 ---
 
-# Publishing version
+# Publishing Version
 
-When releasing a version, we need to upgrade the version numbers of the corresponding packages based on the changeset generated during development, and execute the publish command to publish them to NPM.
+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 as the package management tool. If you need to use other package management tools, please replace them as needed.
+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 following command in the root directory:
+#### Run the bump command in the root directory
 
 ```bash
 pnpm run bump
@@ -27,18 +27,18 @@ When running this command, changesets will automatically perform the following o
 
 - Delete all changeset files under the `.changesets` directory.
 
-- Upgrade the package version number based on the changeset information.
+- 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.
+- 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:
+#### Confirm and submit the current changes
 
 ```bash
 git add .
 git commit -m "release: bump package"
 ```
 
-#### Run the following command in the root directory to publish the package to NPM:
+#### Run the release command in the root directory to publish the package to NPM
 
 ```bash
 pnpm run release
@@ -46,7 +46,7 @@ pnpm run release
 
 ![](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-module-release.png)
 
-#### Push the corresponding tag information to the remote repository:
+#### Push the tag to the remote repository
 
 ```bash
 git push --follow-tags
@@ -54,7 +54,7 @@ git push --follow-tags
 
 ### Monorepo
 
-#### Run the following command in the root directory:
+#### Run the bmp command in the root directory
 
 ```bash
 pnpm run bump
@@ -66,14 +66,14 @@ When running this command, changesets will automatically perform the following o
 
 - Delete all changeset files under the `.changesets` directory.
 
-- Upgrade the version numbers of the relevant packages based on the changeset information. In addition to the packages written in the changeset, changesets will also analyze the dependency relationships of all packages in the Monorepo during execution. If an upgrade is required, the version number will be automatically upgraded accordingly.
+- 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 information 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.
+- 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:
+#### Confirm and submit the current changes
 
 :::info
-Make sure that the automatically upgraded version numbers 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).
+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
@@ -81,19 +81,19 @@ git add .
 git commit -m "release: bump package"
 ```
 
-#### Run the following command in the root directory to publish the package to NPM:
+#### 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 executed to publish them.
+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 execute `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.
+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 corresponding tag information to the remote repository:
+#### Push the tag to the remote repository
 
 ```bash
 git push --follow-tags
@@ -103,17 +103,17 @@ git push --follow-tags
 
 ### Parameters for the `bump` command
 
-- `--snapshot` Generates a timestamp-based version number.
+- `--snapshot`: Generates a timestamp-based version.
 
 ```bash
 pnpm run bump --snapshot canary
 ```
 
-After running, the corresponding upgraded version number 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`.
+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.
+- `--ignore`: Manually ignore some packages during publishing.
 
 For example, if you need to ignore the `module-2` package for this release:
 
@@ -121,7 +121,7 @@ For example, if you need to ignore the `module-2` package for this release:
 pnpm run bump --ignore module-2
 ```
 
-After executing 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.
+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:
 
@@ -131,29 +131,29 @@ pnpm run bump --ignore module-2 --ignore module-3
 
 ### Parameters for the `release` command
 
-- `--otp` Uses `npm token` to execute the release command to publish the corresponding package.
+- `--otp`: Uses `npm token` to publish the package.
 
 ```bash
 pnpm run relese --otp <token>
 ```
 
-- `--tag` Uses a specific tag for local publishing, and `latest` is used by default.
+- `--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.
+- `--ignore-scripts`: Ignores npm scripts during publishing.
 
-When executing the `publish` command, npm will automatically trigger many commands, such as `prepare` and `prepublish`. Using this parameter can ignore the execution of these commands. This parameter is only supported in Monorepo using pnpm.
+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.
+- `--no-git-checks`: Ignores checking the current branch during publishing.
 
-By default, when executing the publish 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.
+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
@@ -161,9 +161,9 @@ pnpm run release --no-git-checks
 
 ## Version Upgrade Strategy
 
-### dependencies or devDependencies dependencies
+### dependencies or devDependencies
 
-#### Only upgrade the patch version of the package itself for patch version dependencies
+- Only upgrade the patch version of the package itself for patch version
 
 For example, the following scenario exists:
 
@@ -171,9 +171,9 @@ There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` ex
 
 The current changeset is the patch version upgrade of `module-1`.
 
-After executing the bump command, only the patch version number of `module-1` will be upgraded.
+After running the `bump` command, only the patch version of `module-1` will be upgraded.
 
-#### Upgrade the major or minor version number of the package itself for major/minor version upgrades, and upgrade the patch version number of the dependent packages
+- 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:
 
@@ -181,11 +181,11 @@ There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` ex
 
 The current changeset is the minor version upgrade of `module-1`.
 
-After executing the bump command, `module-1` will upgrade the `minor` version number, and `module-2` will upgrade the `patch` version number.
+After running the `bump` command, `module-1` will upgrade the `minor` version, and `module-2` will upgrade the `patch` version number.
 
-### peerDependencies dependencies
+### peerDependencies
 
-#### Upgrade the patch version number of the package itself and the dependent package for patch version dependencies
+- Upgrade the patch version of the package itself and the dependent package for patch version dependencies
 
 For example, the following scenario exists:
 
@@ -193,9 +193,9 @@ There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` ex
 
 The current changeset is the patch version upgrade of `module-1`.
 
-After executing the bump command, both `module-1` and `module-2` will upgrade the patch version number.
+After running the `bump` command, both `module-1` and `module-2` will upgrade the patch version.
 
-#### Upgrade the major version number of the dependent package for major/minor version upgrades of the package itself
+- Upgrade the major version of the dependent package for major/minor version upgrades of the package itself
 
 For example, the following scenario exists:
 
@@ -203,9 +203,9 @@ There are two packages in Monorepo, `module-1` and `module-2`, and `module-1` ex
 
 The current changeset is the minor version upgrade of `module-1`.
 
-After executing the bump command, `module-1` will upgrade the `minor` version number, and `module-2` will upgrade the `major` version number.
+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
+- 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.
 
@@ -220,10 +220,10 @@ The upgrade strategy of `peerDependencies` can be modified by configuring `onlyU
 
 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 number of `module-1` is declared using `^`.
+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 executing the `bump` command, only the version number of `module-1` will be upgraded.
+After running the `bump` command, only the version of `module-1` will be upgraded.
 
-Note that if the package version number is in the `0.x.x` range, upgrading the `minor` version number is also beyond the declared version type range.
+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/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

@@ -25,13 +25,13 @@ sidebar_position: 2
 
 ### 模块工程方案
 
-#### 在根目录执行以下命令：
+#### 在根目录执行 change 命令
 
 ```bash
 pnpm run change
 ```
 
-#### 选择本次变更需要升级的版本号类型，点击回车：
+#### 选择本次变更需要升级的版本号类型
 
 ![选择版本类型](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-select-version.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,7 +96,7 @@ feat: test-changeset
 
 change 命令支持以下参数：
 
-- `--empty` 添加一个空的 changeset。
+- `--empty`： 添加一个空的 changeset。
 
 ```bash
 pnpm run change --empty
@@ -107,7 +109,7 @@ pnpm run change --empty
 ---
 ```
 
-- `--open` 使用该参数时，在填写 changelog 步骤会打开系统默认编辑器进行填写。
+- `--open`： 使用该参数时，在填写 changelog 步骤会打开系统默认编辑器进行填写。
 
 ## 注意事项
 

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

@@ -164,7 +164,7 @@ module.exports = {
 
 自定义 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 配置为数组时，第二个参数支持传入默认的配置信息，会对应的使用该参数传递。
 
@@ -195,7 +195,7 @@ commit 配置为 ./my-commit-config.js 即可:
 
 自定义 commit 还可以使用模块工程方案进行管理，提供通用方案。
 
-#### 使用 `npx @modern-js/create@latest` 创建模块工程方案。
+#### 使用 `npx @modern-js/create@latest` 创建模块工程方案
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -204,7 +204,7 @@ commit 配置为 ./my-commit-config.js 即可:
 ? 请选择包管理工具：pnpm
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getAddMessage() {}
@@ -212,11 +212,11 @@ export async function getAddMessage() {}
 export async function getVersionMessage() {}
 ```
 
-#### 将模块发布到 NPM。
+#### 将模块发布到 NPM
 
-#### 在目标仓库根目录安装对应模块，例如 custom-commit。
+#### 在目标仓库根目录安装对应模块，例如 `custom-commit`
 
-#### 配置 changeset 的 commit 配置为包名称。
+#### 配置 changeset 的 commit 配置为包名称
 
 ```json title="package.json"
 {
@@ -229,7 +229,7 @@ export async function getVersionMessage() {}
 
 如果你当前仓库为 Monorepo 工程方案，可以直接使用模块子项目进行管理。
 
-#### 执行 `pnpm run new` 创建模块子项目。
+#### 执行 `pnpm run new` 创建模块子项目
 
 ```md
 ? 请选择你想创建的工程类型：Npm 模块
@@ -238,7 +238,7 @@ export async function getVersionMessage() {}
 ? 请选择开发语言：TS
 ```
 
-#### 实现自定义内容。
+#### 实现自定义内容
 
 ```ts title="src/index.ts"
 export async function getAddMessage() {}
@@ -246,7 +246,7 @@ export async function getAddMessage() {}
 export async function getVersionMessage() {}
 ```
 
-#### 在 Monorepo 根目录添加子项目模块依赖，例如 custom-commit。
+#### 在 Monorepo 根目录添加子项目模块依赖，例如 `custom-commit`
 
 ```json title="package.json"
 {
@@ -257,7 +257,7 @@ export async function getVersionMessage() {}
 }
 ```
 
-#### 配置 changeset 的 commit 配置为包名称。
+#### 配置 changeset 的 commit 配置为包名称
 
 ```json title=".changesets/config.json"
 {

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

@@ -112,7 +112,7 @@ pkg-b @ version 1.0.0
 
 ![关闭 changelog 配置](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/changeset-empty-changelog.png)
 
-配置为 `@changesets/cli/changelog` 将使用官方提供的 Changlog 生成规则，将 changeset 信息转换为 changlog 内容。
+配置为 `@changesets/cli/changelog` 将使用官方提供的 changlog 生成规则，将 changeset 信息转换为 changlog 内容。
 
 配置为数组时，第一个参数为自定义 NPM 包或者路径，第二个参数为需要传入的默认参数配置，自定义格式我们将在后续[自定义 changelog](/guides/topic-detail/changesets/changelog) 章节讲解。
 

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

@@ -48,7 +48,7 @@ Modern.js 提供了自动创建发版 Pull Request 的 Github Action，提供基
 
 #### 使用
 
-在仓库中创建 `.github/workflows/release-pull-request.yml` 文件，填入以下内容：
+- 在仓库中创建 `.github/workflows/release-pull-request.yml` 文件，填入以下内容：
 
 ```yaml
 name: Release Pull Request
@@ -93,15 +93,15 @@ jobs:
           REF: ${{ github.ref }}
 ```
 
-将 Workflow 合并到主分支后，进入 Github 仓库对应的 Action 页面，选择 Release Pull Request：
+- 将 Workflow 合并到主分支后，进入 Github 仓库对应的 Action 页面，选择 Release Pull Request：
 
 ![Release Pull Request Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/action-pull-request.png)
 
-选择本次发布类型，点击 Run workflow 按钮：
+- 选择本次发布类型，点击 Run workflow 按钮：
 
 ![Run Release Pull Request](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/action-pull-request.jpeg)
 
-workflow 运行完成后将自动创建 `Release-${version}` 的 Pull Request，自动完成 `bump` changeset 相关版本号并更新 lock 文件，Pull Request 的内容为执行 `gen-release-note` 命令自动生成的 Release Note。
+- Workflow 运行完成后将自动创建 `Release-${version}` 的 Pull Request，自动完成 `bump` changeset 相关版本号并更新 lock 文件，Pull Request 的内容为执行 `gen-release-note` 命令自动生成的 Release Note。
 
 ![Release Pull Request](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/release-pull-request.jpeg)
 
@@ -111,7 +111,7 @@ Modern.js 提供了自动发布版本 的 Github Action，提供基于选择的
 
 #### 使用
 
-在仓库中创建 `.github/workflows/release.yml` 文件，填入以下内容：
+- 在仓库中创建 `.github/workflows/release.yml` 文件，填入以下内容：
 
 ```yaml
 name: Release
@@ -160,16 +160,16 @@ jobs:
           REF: ${{ github.ref }}
 ```
 
-配置仓库的 NPM_TOKEN:
+- 配置仓库的 NPM_TOKEN:
 
 ![配置 Token](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/github-set-npm-token.png)
 
-将 Workflow 合并到主分支后，进入 Github 仓库对应的 Action 页面，选择 Release：
+- 将 Workflow 合并到主分支后，进入 Github 仓库对应的 Action 页面，选择 Release：
 
 ![Release Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/release-action.png)
 
-选择分支名称和发布版本类型，点击 Run workflow 按钮：
+- 选择分支名称和发布版本类型，点击 Run workflow 按钮：
 
 ![Run Release Action](https://lf3-static.bytednsdoc.com/obj/eden-cn/zq-uylkvT/ljhwZthlaukjlkulzlp/run-release-workflow.png)
 
-Workflow 将自动完成仓库 build 和发布到 NPM 流程。
+- Workflow 将自动完成仓库 build 和发布到 NPM 流程。