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

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

@@ -4,7 +4,7 @@ sidebar_position: 8
 
 # Customizing Release Note Format
 
-Modern.js provides the `modern gen-release-note` command, which supports automatically generating Release Note information through the current existing changeset and git commit information. Before executing the release command, you can execute this command to generate the Release Note for this release.
+Modern.js provides the `modern gen-release-note` command, which supports automatically generating Release Note through the current existing changeset and git commit information. Before running the release command, you can run this command to generate the Release Note for this release.
 
 The default generated Release Note format is:
 
@@ -12,25 +12,23 @@ The default generated Release Note format is:
 - fix: add missing type definitions by @zllkjc in https://github.com/web-infra-dev/modern.js/pull/3835
 ```
 
-Obtain the Pull Request ID of the changeset through the commit information, and generate a Github link, which includes the changeset's changelog information and author information.
+Get the Pull Request ID of the changeset through the commit information, and generate a Github link, which includes the changeset's changelog information and author information.
 
 :::info
-To obtain author information, you need to provide the Github Token environment variable, which is passed in through GITHUB_AUTH_TOKEN.
+To get author information, you need to provide the Github Token environment variable, which is passed in through GITHUB_AUTH_TOKEN.
 :::
 
 When the default generated Release Note logic cannot meet the requirements, custom Release Note format is supported.
 
 ## Information
 
-### Information Required for Customizing Release Note
+### getReleaseInfo
 
 To generate Release Note information, some information needs to be collected, such as commit ID, Pull Request ID, commit message, etc.
 
 This logic can be implemented through the `getReleaseInfo` function.
 
-#### getReleaseInfo
-
-##### Params
+#### Params
 
 - commit
 
@@ -42,29 +40,37 @@ The result of executing `git log --pretty=format:%h--%s--%ae .changeset/${change
 
 - commitObj
 
-Preliminary analysis of the commit to obtain basic information.
+Basic information about commit.
 
 ```ts
+export enum CommitType {
+  Performance = 'performance',
+  Features = 'features',
+  BugFix = 'bugFix',
+  Doc = 'doc',
+  Other = 'other',
+}
+
 interface Commit {
   id: string; // commit id
-  type: 'feature' | 'fix'; // commit 类型，默认通过开头字符串如果为 fix，类型为 fix，其他为 feature
-  repository?: string; // 参数传入的 repo 信息或者 package.json 中定义的 repository 信息
+  type: CommitType;
+  repository?: string; // Repo information passed in as a parameter or defined in package.json
   pullRequestId?: string;
   author?: string;
-  message: string; // commit message
-  summary: string; // changeset summary
-  summary_zh: string; // changeset zh summary
+  message: string; // Commit message
+  summary: string; // Changeset summary
+  summary_zh: string; // Changeset summary in Chinese
   [key: string]: string | undefined;
 }
 ```
 
-##### Returns
+#### Returns
 
 commitObj, the complete commit object after supplementation.
 
-##### Default Implementation
+#### Default Implementation
 
-The default implementation of Modern.js is to split out the Pull Request ID based on the commit information, and obtain the user information based on the commit ID and add it to the commitObj.
+The default implementation of Modern.js is to split out the Pull Request ID based on the commit information, and get the user information based on the commit ID and add it to the commitObj.
 
 ```ts
 function getReleaseInfo(commit: string, commitObj: Commit) {
@@ -108,19 +114,17 @@ const commitRegex = /(.*)\(#(\d*)\)/;
 }
 ```
 
-### Generating Release Note Based on Obtained Information
+### getReleaseNoteLine
 
-Generate the corresponding Release Note based on the commit object information obtained in `getReleaseInfo`.
+Generate the corresponding Release Note based on the commit object information getted in `getReleaseInfo`.
 
 This logic can be implemented through the `getReleaseNoteLine` function.
 
-#### getReleaseNoteLine
-
-##### Params
+#### Params
 
 - commit
 
-The type is the same as the above commitObj type.
+The type is the same as the above `commitObj` type.
 
 - lang
 
@@ -128,11 +132,11 @@ Type: string;
 
 Get the Release Note information of the corresponding language, supporting `en` and `zh`, the default is `en`.
 
-##### Returns
+#### Returns
 
 The generated Release Note.
 
-##### Default Implementation
+#### Default Implementation
 
 The default implementation of Modern.js is:
 
@@ -200,11 +204,11 @@ You can also define the command parameters directly in `package.json`:
 
 Run the command `pnpm run gen-release-note` directly.
 
-### Using Module Project
+### Using NPM Module
 
-Customizing release note can also be managed using the module project to provide a common solution.
+Customizing release note can also be managed using the NPM module project to provide a common solution.
 
-#### Use `npx @modern-js/create@latest` to create a module project.
+#### Use `npx @modern-js/create@latest` to create a module project
 
 ```md
 ? Please select the type of project you want to create: Npm Module
@@ -221,9 +225,9 @@ export function getReleaseInfo() {}
 export function getReleaseNoteLine() {}
 ```
 
-#### Publish the module to NPM.
-#### Install the corresponding module in the root directory of the target repository, such as `custom-release-note`.
-#### Run the `gen-release-note` command with the `custom` parameter added.
+#### Publish the module to NPM
+#### Install the corresponding module in the root directory of the target repository, such as `custom-release-note`
+#### Run the `gen-release-note` command with the `custom` parameter added
 
 ```bash
 pnpm run gen-release-note --custom custom-release-note
@@ -231,9 +235,9 @@ pnpm run gen-release-note --custom custom-release-note
 
 ### Using Monorepo Sub-Project
 
-If your current repository is Monorepo, you can directly manage it using module sub-projects.
+If your current repository is Monorepo, you can directly manage it using NPM module sub-projects.
 
-#### Run `pnpm run new` to create a module sub-project.
+#### Run `pnpm run new` to create a module sub-project
 
 ```md
 ? Please select the type of project you want to create: Npm Module
@@ -250,7 +254,7 @@ export function getReleaseInfo() {}
 export function getReleaseNoteLine() {}
 ```
 
-#### Add the sub-project module dependency, such as `custom-release-note`, to the Monorepo root directory.
+#### Add the sub-project module dependency, such as `custom-release-note`, to the Monorepo root directory
 
 ```json title="package.json"
 {
@@ -260,7 +264,7 @@ export function getReleaseNoteLine() {}
 }
 ```
 
-#### Run the `gen-release-note` command with the `custom` parameter added.
+#### Run the `gen-release-note` command with the `custom` parameter added
 
 ```bash
 pnpm run gen-release-note --custom custom-release-note

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

@@ -2,17 +2,17 @@
 sidebar_position: 4
 ---
 
-# Publishing a pre-release version
+# Publishing Pre-Release Version
 
 Before doing an actual release, we also need to publish a pre-release version for internal testing and user use. Changesets also support publishing pre-release versions.
 
 ## 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.
 :::
 
-#### Run the following command to upgrade the version number of the pre-release version:
+#### Run the bump command to upgrade the version of the pre-release
 
 ```bash
 pnpm run bump --canary --preid <preid>
@@ -24,17 +24,17 @@ After using the `--canary` parameter, the `bump` command completes the following
 
 - `changeset pre enter <preid>`: Enters pre-release mode.
 
-- `changeset version`: Upgrades the version number.
+- `changeset version`: Upgrades the version.
 
 - `changeset pre exit`: Exits pre-release mode.
 
 #### Check the changes and submit
 
-Check whether the version number changes are correct and submit the changes.
+Check whether the version changes are correct and submit the changes.
 
 It is recommended to perform pre-release operations not on the main branch and not merge them into the main branch. After the pre-release verification is completed, an actual version can be directly released based on the main branch.
 
-#### Run the following command to publish the pre-release version:
+#### Run the release command to publish the pre-release version:
 
 ```bash
 pnpm run release --tag <tag>

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 步骤会打开系统默认编辑器进行填写。
 
 ## 注意事项