@rsdoctor/docs 1.0.0-beta.3 → 1.0.0-rc.0

package/README.md

@@ -1,4 +1,4 @@
-# Rsdoctor Website
+# Rsdoctor website
 
 ## Writing style guide
 

package/docs/en/blog/topic/duplicate-pkg-problem.mdx

@@ -1,6 +1,6 @@
 # Duplicate dependency problem
 
-Rsdoctor will report cases where multiple duplicate dependencies exist in the same builder's artifact.
+Rsdoctor will report cases where multiple duplicate dependencies exist in the same bundler's artifact.
 
 <img src="https://assets.rspack.dev/others/assets/rsdoctor/bundle-alerts.png" />
 
@@ -8,7 +8,7 @@ Rsdoctor will report cases where multiple duplicate dependencies exist in the sa
 
 - **Security**
   - Many packages adopt singleton mode and are only loaded once by default. Examples include core-js, react, and some component libraries. Having multiple versions coexist can cause runtime errors.
-- **Runtime Perßformance**
+- **Runtime Performance**
   - Increases artifact size, slowing down network transmission
   - Same code for the same functionality runs multiple times
 
@@ -38,10 +38,9 @@ However, before using them, it is important to consider the compatibility betwee
 
 #### Use [resolve.alias](https://www.rspack.dev/config/resolve.html#resolvealias)
 
-Almost all builders support modifying the paths for resolving npm packages. Therefore, we can eliminate duplicate dependencies by manually specifying the resolve paths for packages during compilation. For example, using **Rspack** or **Webpack**, if `lodash` is duplicated in the build, we can configure it as follows to specify the resolve paths for all `lodash` packages to the `node_modules` directory in the current directory.
+Almost all bundlers support customizing the resolution paths for npm packages. Therefore, we can eliminate duplicate dependencies by manually specifying the resolve paths for packages during compilation. For example, using **Rspack** or **Webpack**, if `lodash` is duplicated in the build, we can configure it as follows to specify the resolve paths for all `lodash` packages to the `node_modules` directory in the current directory.
 
-```js
-// webpack.config.js/rspack.config.js
+```js title="rspack.config.js"
 const path = require('path');
 
 module.exports = {
@@ -71,7 +70,7 @@ In this project, the `web` app depends on `react@18.2.0` and imports `component`
 │       │   └── react      -> ../../../node_modules/.pnpm/react@18.2.0
 │       ├── src
 │       │   └── index.js
-│       ├── webpack.config.js
+│       ├── rspack.config.js
 │       └── package.json
 └── packages
     └── component
@@ -82,14 +81,14 @@ In this project, the `web` app depends on `react@18.2.0` and imports `component`
         └── package.json
 ```
 
-When executing `webpack build` under `apps/web`, the code in the `web` directory will be resolved to `react@18.2.0`, and then the code in the `component` directory will be resolved to `react@18.1.0`. This results in the output of the web project containing two versions of `React`.
+When executing `rspack build` under `apps/web`, the code in the `web` directory will be resolved to `react@18.2.0`, and then the code in the `component` directory will be resolved to `react@18.1.0`. This results in the output of the web project containing two versions of `React`.
 
 #### Solution
 
-This issue can be resolved using the `resolve.alias` configuration in the builder, such as `Rspack` or `Webpack`. By specifying the resolve path for `React` to only resolve to `apps/web/node_modules/react`, you can ensure that only one version of `React` is included in the output. Here is an example code:
+This issue can be resolved using the `resolve.alias` configuration of the bundler, such as Rspack or webpack. By specifying the resolve path for `React` to only resolve to `apps/web/node_modules/react`, you can ensure that only one version of `React` is included in the output. Here is an example code:
 
 ```javascript
-// apps/web/webpack.config.js
+// apps/web/rspack.config.js
 const path = require('path');
 
 module.exports = {
@@ -116,7 +115,7 @@ This handling method also applies to projects with duplicate packages caused by
 │       │   └── debug      ->  ../../../node_modules/.pnpm/debug@4.3.4
 │       ├── src
 │       │   └── index.js
-│       ├── webpack.config.js
+│       ├── rspack.config.js
 │       └── package.json
 └── packages
     └── component
@@ -127,14 +126,14 @@ This handling method also applies to projects with duplicate packages caused by
         └── package.json
 ```
 
-In this project, when executing `webpack build` under `apps/web`, the code in the `web` directory will be resolved to `axios@0.27.2_debug@4.3.4`, and then the code in the `packages/component` directory will be resolved to `axios@0.27.2`.
+In this project, when executing `rspack build` under `apps/web`, the code in the `web` directory will be resolved to `axios@0.27.2_debug@4.3.4`, and then the code in the `packages/component` directory will be resolved to `axios@0.27.2`.
 
 Although they are the same version, they have different paths, resulting in two copies of `axios` in the output.
 
 The solution is to configure the `web` project to only resolve the `axios` package under the `web` directory's `node_modules`.
 
 ```javascript
-// apps/web/webpack.config.js
+// apps/web/rspack.config.js
 alias: {
   'axios': path.resolve(__dirname, 'node_modules/axios')
 }

package/docs/en/guide/more/faq.mdx

@@ -15,7 +15,7 @@ new RsdoctorRspackPlugin({
 ## Loader time-consuming data is inaccurate?
 
 The time-consuming data provided by Rsdoctor for loaders is an **estimated time**. Why can't it accurately measure the timing? It's because we know that loader execution can be both **asynchronous** and **synchronous**.
-Additionally, the builder will **parallelize the execution** of multiple non-conflicting loader functions. Since JavaScript is single-threaded, multiple loader functions can **compete for the current task queue**.
+Additionally, the bundler will **parallelize the execution** of multiple non-conflicting loader functions. Since JavaScript is single-threaded, multiple loader functions can **compete for the current task queue**.
 Furthermore, the asynchronous logic within loader functions cannot be recognized, causing a single loader function to potentially span across the execution of multiple other loaders. As a result, there are three possible cases, as shown in the following diagram:
 
 <img

package/docs/en/guide/rules/rules.mdx

@@ -8,9 +8,9 @@ Please refer to the [Linter Type](#linter-type) in this document for the type de
 
 :::
 
-### [E1001] Duplicate Packages
+### [E1001] Duplicate packages
 
-#### Rule Details
+#### Rule details
 
 - The `Duplicate Packages` card displays the number of duplicate third-party packages in the project. Clicking the image allows you to view the specific details of the duplicate third-party packages. Note: The third-party packages referred to here are all bundled third-party packages.
 
@@ -91,13 +91,13 @@ enum CheckVersion {
 }
 ```
 
-#### Duplicate Package Optimization Problem
+#### Duplicate package optimization problem
 
 Please refer to the [Duplicate Package Optimization Solution](../../blog/topic/duplicate-pkg-problem).
 
 Clicking 「**More**」 can view the corresponding rule explanation.
 
-### [E1002] Cross Chunks Package
+### [E1002] Cross chunks package
 
 The cross chunks duplicate package rule can scan **duplicate packages in different `chunks`**. These duplicate packages may also lead to redundant code in the build artifacts, depending on the business logic and the size of the redundant code.
 
@@ -111,7 +111,7 @@ The cross chunks duplicate package rule can scan **duplicate packages in differe
 
 Please refer to [[E1002] Cross Chunks Packages](../more/rules)
 
-### [E1003] Loader Performance Optimization
+### [E1003] Loader performance optimization
 
 This module allows you to visually see some warning information about our project's compilation, which can help us further optimize the project's compilation performance.
 
@@ -119,7 +119,7 @@ This module allows you to visually see some warning information about our projec
 
 Please refer to [[E1003] Loader Performance Optimization](../more/rules)
 
-#### Configuration Type
+#### Configuration type
 
 - **ignore**: Can include strings or regular expressions, used to specify the loaders to be ignored.
 - **threshold**: Represents the total time threshold for the loader, in milliseconds. If the loader's execution time exceeds this threshold, it may trigger warnings or errors. The default value is 5000 milliseconds.
@@ -145,7 +145,7 @@ interface Config {
 }
 ```
 
-### [E1004] ECMA Version Check
+### [E1004] ECMA version check
 
 This rule is used to detect incompatible advanced syntax. When scanning the rule, the configuration of `browserslist` is prioritized; if `browserslist` is not configured, manual detection is required, as shown below:
 
@@ -171,7 +171,7 @@ export default {
 };
 ```
 
-#### Type Definitions
+#### Type definitions
 
 ```ts
 type CheckSyntaxOptions = {
@@ -205,7 +205,7 @@ type CheckSyntaxOptions = {
 
 For more `ECMA Version Check` configuration options, please refer to [ECMA Version Check Options](https://github.com/rspack-contrib/rsbuild-plugin-check-syntax?tab=readme-ov-file#options)
 
-### [E1005] Default Import Check
+### [E1005] Default import check
 
 Typically, Rspack automatically supports different types of modules, but in some cases, compatibility operations may fail. For example, when using `Default Import` to import a `cjs` module, if the module does not have a compatible statement (such as `exports.default`), issues may arise.
 
@@ -224,7 +224,7 @@ interface Config {
 }
 ```
 
-## Linter Type
+## Linter type
 
 - The type definition for the `linter` field is as follows:
 

package/docs/en/guide/start/cli.mdx

@@ -96,7 +96,7 @@ import { execute } from '@rsdoctor/cli';
 
 **execute()**
 
-The `execute` asynchronous function is the execution function of Rsdoctor CLI. By calling the `execute` function, it will automatically parse [process.argv](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processargv) and invoke different commands.
+The `execute` asynchronous function is the execution function of Rsdoctor CLI. By calling the `execute` function, it will automatically parse [process.argv](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processargv) and invoke different commands.
 
 **execute('analyze', \{...\})**
 

package/docs/en/guide/start/quick-start-shared.mdx

@@ -1,4 +1,4 @@
-## Step 2: Register plugin
+## Step 2: register plugin
 
 After the dependency installation, you need to integrate the Rsdoctor plugin into your project. Below are some examples of common tools and frameworks:
 
@@ -141,7 +141,7 @@ export default defineConfig({
 
 ---
 
-## Step 3: Run build
+## Step 3: run build
 
 Now, you can run the **build** command in the project. After the build is complete, Rsdoctor will automatically open the analysis page of this build.
 

package/docs/en/guide/start/quick-start.mdx

@@ -2,7 +2,7 @@
 
 This document will explain how to access the Rsdoctor ability.
 
-## Step 1: Install dependencies
+## Step 1: install dependencies
 
 import { PackageManagerTabs } from '@theme';
 
@@ -15,10 +15,10 @@ For projects based on Rspack or Rsbuild, install the following dependencies:
 ### Webpack projects
 
 :::tip
-Not supported in Webpack 4.
+Rsdoctor only supports webpack >= 5.
 :::
 
-For projects based on Webpack, install the following dependencies:
+For projects based on webpack, install the following dependencies:
 
 <PackageManagerTabs command="add @rsdoctor/webpack-plugin -D" />
 

package/docs/en/guide/usage/bundle-alerts.mdx

@@ -1,4 +1,4 @@
-# Bundle Alerts
+# Bundle alerts
 
 ## Introduction
 

package/docs/en/guide/usage/bundle-size.mdx

@@ -19,7 +19,7 @@ Click on the **"Bundle Size"** option in the navigation bar to view the Bundle a
 
 - **`Assets`**: Resources refer to images, fonts, media, and other file types. They are the files that ultimately exist in the output folder. Each Chunk has corresponding [Assets resources](https://webpack.js.org/concepts/under-the-hood/#chunks).
 - **`Module`**: One or more Modules combine to form a Chunk. For more information about Module types, please refer to [Rspack Modules](https://www.rspack.dev/api/modules.html) and [Webpack Modules](https://webpack.js.org/concepts/modules/#what-is-a-webpack-module).
-- **`Bundle Size`**: The final packaged size of the resource artifact, which is the final size after being processed by the builder.
+- **`Bundle Size`**: The final packaged size of the resource artifact, which is the final size after being processed by the bundler.
 - **`Module Bundled Source & Size`**: **Module Parsed Source** refers to the final code fragment of the **Module** in the packaged artifact, and **Module Parsed Size** refers to the size of the final code fragment of the **Module** in the packaged artifact.
 - **`Package Count`**: The number of third-party packages.
 - **`Initial Chunk`**: The **initial** chunk is the main chunk of the entry point. This chunk contains all the modules specified by the entry point and their dependencies, unlike the **chunks** for "on-demand loading".
@@ -82,7 +82,7 @@ The top toolbar from left to right includes: the search tool for **Assets**, the
 
 <img src="https://assets.rspack.dev/others/assets/rsdoctor/bundle-size-analysis-selects.png" />
 
-#### Search Module
+#### Search module
 
 Search for which Assets the Module is located in. As shown in the figure, you can see the results of matching the search Module keyword.
 
@@ -91,7 +91,7 @@ Search for which Assets the Module is located in. As shown in the figure, you ca
   src="https://assets.rspack.dev/others/assets/rsdoctor/search-modules.png"
 />
 
-#### Search Module
+#### Search module
 
 The module search functionality is supported, allowing users to click the "**Search Module**" button to open the module search dialog. By entering the module name, users can quickly locate and view the module's position in the Assets, making it easier to analyze the module's reference relationships and size. The search determines which Assets the Module is located in.
 
@@ -149,17 +149,16 @@ The added code segment will affect the analysis capability of the bundle.
 
 Rsdoctor is compatible with the logic of adding code using the BannerPlugin, but it is not enabled by default because Rsdoctor needs to add tag code. The Rsdoctor BannerPlugin capability is enabled in the following two cases:
 
-1. The project uses the BannerPlugin in `rspack.config.j|ts` or `webpack.config.j|ts`.
+1. The project uses the BannerPlugin in `rspack.config.(js|ts)` or `webpack.config.(js|ts)`.
 
 2. Enable Rsdoctor BannerPlugin capability through Rsdoctor options by setting `supports.banner`:
 
 ```ts
-new RsdoctorRspackPlugin (
+new RsdoctorRspackPlugin({
   supports: {
-    banner: true
-  }
-)
-
+    banner: true,
+  },
+});
 ```
 
 - Note: Enabling `drop_console` will affect Rsdoctor's analysis of the BannerPlugin. Therefore, you can disable `drop_console` when `RSDOCTOR = true`.

package/docs/en/guide/usage/compile-alerts.mdx

@@ -1,4 +1,4 @@
-# Compile Alerts
+# Compile alerts
 
 We have integrated some capabilities based on compilation data detection. If the current compilation result contains data that hits the rules we define, the `Compile Alerts` module will appear at the bottom of the **Rsdoctor** main interface, as shown in the image below:
 

package/docs/en/guide/usage/compile-overall.mdx

@@ -19,12 +19,12 @@ For each compilation phase, if the time data is displayed in <u>blue</u>, it mea
 
 The following table explains the meaning and code implementation of each phase in the card:
 
-| Phase Name                               | Description                                                                                 | Code Implementation                                                                                                                                                                                                              |
-| ---------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| <b><i>Bootstrap -> BeforeCompile</i></b> | Represents the time taken from project startup to before compilation starts                 | <ul><li>In `Webpack` or `Rspack` projects: Reports [process.uptime()](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processuptime) as the <b>duration</b> when **compiler.hooks.beforeCompile** is called</li></ul> |
-| <b><i>Compile</i></b>                    | Represents the total time taken for the project compilation                                 | <ul><li>In `Webpack` or `Rspack` projects: The <b>start time</b> is the time when **compiler.hooks.beforeCompile** is called, and the <b>end time</b> is the time when **compiler.hooks.afterCompile** is called</li></ul>       |
-| <b><i>AfterCompile -> Done</i></b>       | Represents the time taken from compilation completion to the end of the entire process      | <ul><li>In `Webpack` or `Rspack` projects: The <b>start time</b> is the time when **compiler.hooks.afterCompile** is called, and the <b>end time</b> is the time when **compiler.hooks.done** is called</li></ul>                |
-| <b><i>Minify</i></b>                     | Represents the time taken for file compression during the compilation process in most cases | <ul><li>In `Webpack` or `Rspack` projects: Calculates the sum of the time taken for each call of **compilation.hooks.optimizeChunkAssets** and **compilation.hooks.processAssets**</li></ul>                                     |
+| Phase Name                               | Description                                                                                 | Code Implementation                                                                                                                                                                           |
+| ---------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| <b><i>Bootstrap -> BeforeCompile</i></b> | Represents the time taken from project startup to before compilation starts                 | <ul><li>Reports [process.uptime()](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processuptime) as the <b>duration</b> when **compiler.hooks.beforeCompile** is called</li></ul> |
+| <b><i>Compile</i></b>                    | Represents the total time taken for the project compilation                                 | <ul><li>The <b>start time</b> is the time when **compiler.hooks.beforeCompile** is called, and the <b>end time</b> is the time when **compiler.hooks.afterCompile** is called</li></ul>       |
+| <b><i>AfterCompile -> Done</i></b>       | Represents the time taken from compilation completion to the end of the entire process      | <ul><li>The <b>start time</b> is the time when **compiler.hooks.afterCompile** is called, and the <b>end time</b> is the time when **compiler.hooks.done** is called</li></ul>                |
+| <b><i>Minify</i></b>                     | Represents the time taken for file compression during the compilation process in most cases | <ul><li>Calculates the sum of the time taken for each call of **compilation.hooks.optimizeChunkAssets** and **compilation.hooks.processAssets**</li></ul>                                     |
 
 ## Usage instructions
 
@@ -56,7 +56,7 @@ Hovering over a data point in the chart will display the following information i
 
 In this section, you can navigate to "Compile Analysis" -> "Loader Analysis" -> [**"Loader Timeline"**](./loaders-timeline.mdx) in the navigation bar to view the timeline of loader compilation time.
 
-### AfterCompile -> Done details
+### AfterCompile -> done details
 
 By **clicking on the data of the `AfterCompile -> Done` phase**, a popup will appear on the page, as shown in the following image:
 

package/docs/en/guide/usage/project-overall.mdx

@@ -18,7 +18,7 @@ In the main page of **Rsdoctor**, we can see a card named `Project Overall`, whi
 | <b><i>errors</i></b>  | Represents the **error** level rules detected by Rsdoctor during the current run                                                                              |
 | <b><i>warns</i></b>   | Represents the **warn** level rules detected by Rsdoctor during the current run                                                                               |
 | <b><i>webpack</i></b> | Represents the Webpack version obtained during the current run                                                                                                |
-| <b><i>cwd</i></b>     | Represents the current working directory during the current run, i.e., [process.cwd()](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processcwd) |
+| <b><i>cwd</i></b>     | Represents the current working directory during the current run, i.e., [process.cwd()](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processcwd) |
 | <b><i>cpu</i></b>     | Represents the CPU information                                                                                                                                |
 | <b><i>memory</i></b>  | Represents the memory information during the current run                                                                                                      |
 | <b><i>node</i></b>    | Represents the version number of [Node.js](https://nodejs.org/)                                                                                               |

package/docs/en/guide/usage/rule-config.mdx

@@ -1,4 +1,4 @@
-# Compilation Diagnostic Rules
+# Compilation diagnostic rules
 
 Building diagnostic rules is similar to `ESLint` like lint tools, but different from it in that `ESLint` performs code scanning and is unrelated to the build process. In contrast, the code diagnostics here are closely related to the build process of `Rspack or Webpack`, incorporating many internal parameters generated during the build process to aid judgment, such as ModuleGraph, Webpack's internal markings for each module, and runtime added after code transformation, among others.
 
@@ -16,7 +16,7 @@ During the build process, if issues are discovered, they will be visible in the
   src="https://assets.rspack.dev/others/assets/rsdoctor/bundle-alerts.png"
 />
 
-## How to Use
+## How to use
 
 Currently, Rsdoctor provides **built-in rules** and **custom rules**.
 
@@ -32,6 +32,6 @@ The existing diagnostic tool includes multiple rules, all of which are enabled b
 
 For specific details, refer to [Built-in Rules](/guide/rules/rules).
 
-### Custom Rules
+### Custom rules
 
 Rsdoctor also collects analyzed data and allows users to integrate custom rules through the Linter API. For details on custom rules, refer to [Custom Rules](/guide/rules/rule-custom).

package/docs/zh/blog/topic/duplicate-pkg-problem.mdx

@@ -37,10 +37,9 @@ Rsdoctor 会在产物预警中报告对同一份产物中含有多个重复依
 
 #### 使用 [resolve.alias](https://www.rspack.dev/config/resolve.html#resolvealias)
 
-基本所有的构建器都支持对 npm 包解析的路径进行修改。因此我们可以通过在编译时手动指定 package 的 resolve 路径，来达到消除重复依赖的目的，例如：以 **Rspack** 或 **Webpack** 为例，如果 `lodash` 重复打包，我们可以进行如下配置，将所有 `lodash` 的 resolve 路径指定到当前目录的 `node_modules` 中。
+几乎所有的打包工具都提供了自定义 npm 包解析路径的功能。因此我们可以通过在编译时手动指定 package 的 resolve 路径，来达到消除重复依赖的目的，例如：以 **Rspack** 或 **Webpack** 为例，如果 `lodash` 重复打包，我们可以进行如下配置，将所有 `lodash` 的 resolve 路径指定到当前目录的 `node_modules` 中。
 
-```js
-// webpack.config.js/rspack.config.js
+```js title="rspack.config.js"
 const path = require('path');
 
 module.exports = {
@@ -70,7 +69,7 @@ module.exports = {
 │       │   └── react      -> ../../../node_modules/.pnpm/react@18.2.0
 │       ├── src
 │       │   └── index.js
-│       ├── webpack.config.js
+│       ├── rspack.config.js
 │       └── package.json
 └── packages
     └── component
@@ -81,14 +80,14 @@ module.exports = {
         └── package.json
 ```
 
-在 `apps/web` 下执行 `webpack build`，打包 web 下的代码时，会解析到 `react@18.2.0`，接着打包 `component` 下的代码时，会解析到 `react@18.1.0`，这导致 web 项目的产物中同时含有两个版本的 `React`。
+在 `apps/web` 下执行 `rspack build`，打包 web 下的代码时，会解析到 `react@18.2.0`，接着打包 `component` 下的代码时，会解析到 `react@18.1.0`，这导致 web 项目的产物中同时含有两个版本的 `React`。
 
 #### 解决方案
 
-此问题可以通过构建器的 [resolve.alias](https://www.rspack.dev/config/resolve.html#resolvealias) 来解决。让 `Rspack` 或 `Webpack` 解析 `React` 时只解析到 `apps/web/node_modules/react` 这一个版本，示例代码如下：
+此问题可以通过打包工具的 [resolve.alias](https://www.rspack.dev/config/resolve.html#resolvealias) 来解决。让 Rspack 或 webpack 解析 `React` 时只解析到 `apps/web/node_modules/react` 这一个版本，示例代码如下：
 
 ```javascript
-// apps/web/webpack.config.js
+// apps/web/rspack.config.js
 const path = require('path');
 
 module.exports = {
@@ -115,7 +114,7 @@ module.exports = {
 │       │   └── debug      ->  ../../../node_modules/.pnpm/debug@4.3.4
 │       ├── src
 │       │   └── index.js
-│       ├── webpack.config.js
+│       ├── rspack.config.js
 │       └── package.json
 └── packages
     └── component
@@ -126,12 +125,12 @@ module.exports = {
         └── package.json
 ```
 
-在该项目中，在 `apps/web` 下执行 `webpack build`，打包 web 下的代码时，会解析到 `axios@0.27.2_debug@4.3.4`，接着打包 `packages/component` 下的代码时，会解析到 `axios@0.27.2`，它们虽然是同一版本，但路径不同，产物中也会存在两份 `axios`。
+在该项目中，在 `apps/web` 下执行 `rspack build`，打包 web 下的代码时，会解析到 `axios@0.27.2_debug@4.3.4`，接着打包 `packages/component` 下的代码时，会解析到 `axios@0.27.2`，它们虽然是同一版本，但路径不同，产物中也会存在两份 `axios`。
 
 解决方案如下，让 `web` 项目构建时都只解析到 `web` 下 `node_modules` 的 `axios` 包即可。
 
 ```javascript
-// apps/web/webpack.config.js
+// apps/web/rspack.config.js
 alias: {
   'axios': path.resolve(__dirname, 'node_modules/axios')
 }

package/docs/zh/config/options/options.mdx

@@ -87,9 +87,9 @@ new RsdoctorWebpackPlugin({
 
 <Badge text="Version: 0.4.0" type="warning" />
 
-- **Type:** [BriefType](#brieftype)
-- **Optional:** `true`
-- **Default:** undefined
+- **类型：** [BriefType](#brieftype)
+- **可选：** `true`
+- **默认值：** `undefined`
 
 Brief 模式更多配置，如下：
 
@@ -107,9 +107,9 @@ interface BriefConfig {
 
 ### disableClientServer
 
-- **Type:** `boolean`
-- **Optional:** `true`
-- **Default:** `false`
+- **类型：** `boolean`
+- **可选：** `true`
+- **默认值：** `false`
 
 :::tip
 建议在 CI 环境下将 disableClientServer 设置为 true，否则启动的服务会卡住 pipeline 流程.
@@ -123,9 +123,9 @@ interface BriefConfig {
 
 #### enableNativePlugin
 
-- Type: `boolean`
-- Optional: true
-- Default: false
+- **类型：** `boolean`
+- **可选：** `true`
+- **默认值：** `false`
 
 ##### Description
 
@@ -133,7 +133,7 @@ interface BriefConfig {
 
 - enableNativePlugin：是否开启 Rspack 原生插件，开启后可大幅降低 Rsdoctor 自身的分析耗时。
 
-- Example
+- **示例：**
 
 ```js
 new RsdoctorRspackPlugin({
@@ -143,9 +143,9 @@ new RsdoctorRspackPlugin({
 
 ### features
 
-- **Type:** [RsdoctorWebpackPluginFeatures](#rsdoctorwebpackpluginfeatures) | [Array\<keyof RsdoctorWebpackPluginFeatures\>](#rsdoctorwebpackpluginfeatures) | [RsdoctorRspackPluginFeatures](#rsdoctorrspackpluginfeatures) | [Array\<keyof RsdoctorRspackPluginFeatures\>](#rsdoctorrspackpluginfeatures)
-- **Optional:** `true`
-- **Default:** `['loader', 'plugins', 'bundle']`
+- **类型：** [RsdoctorWebpackPluginFeatures](#rsdoctorwebpackpluginfeatures) | [Array\<keyof RsdoctorWebpackPluginFeatures\>](#rsdoctorwebpackpluginfeatures) | [RsdoctorRspackPluginFeatures](#rsdoctorrspackpluginfeatures) | [Array\<keyof RsdoctorRspackPluginFeatures\>](#rsdoctorrspackpluginfeatures)
+- **可选：** `true`
+- **默认值：** `['loader', 'plugins', 'bundle']`
 
 #### features values
 
@@ -195,9 +195,9 @@ import FeaturesRspack from '@zh/shared/features-rspack.md';
 
 <Badge text="Version: 0.4.0" type="warning" />
 
-- **Type:** `normal | brief | lite`
-- **Optional:** `true`
-- **Default:** `normal`
+- **类型：** `normal | brief | lite`
+- **可选：** `true`
+- **默认值：** `normal`
 
 选择使用的 Rsdoctor 构建报告模式，有以下几种：
 
@@ -211,25 +211,25 @@ import ModeIntro from '@zh/shared/mode-intro.md';
 
 #### compressData
 
-- **Type:** boolean
-- **Optional:** `true`
-- **Default:** true
+- **类型：** `boolean`
+- **可选：** `true`
+- **默认值：** `true`
 
 compressData 用于配置是否将 [outputDir]/.rsdoctor 下的分析数据进行压缩处理。
 
 #### reportCodeType
 
-- Type: `{ noModuleSource?: boolean; noAssetsAndModuleSource?: boolean }`
-- Optional: true
-- Default: undefined
-- Description
+- **类型：** `{ noModuleSource?: boolean; noAssetsAndModuleSource?: boolean }`
+- **可选：** `true`
+- **默认值：** `undefined`
+- **描述：**
 
   - 选择输出的分析数据：
     - 默认是所有完整数据；
     - noModuleSource: true 是输出除了 module 代码之外的数据，Module 代码即 Bundle 内一个一个文件的打包模块代码。
     - noAssetsAndModuleSource: true 是输出除了 module 代码和 Assets 产物代码之外的数据。
 
-- Example
+- **示例：**
 
 ```js
 new RsdoctorRspackPlugin({
@@ -239,17 +239,17 @@ new RsdoctorRspackPlugin({
 
 #### reportDir
 
-- **Type:** string
-- **Optional:** `true`
-- **Default:** undefined
+- **类型：** `string`
+- **可选：** `true`
+- **默认值：** `undefined`
 
 Rsdoctor 报告输出目录，默认是构建产物输出目录。
 
 ### port
 
-- **Type:** `number`
-- **Optional:** `true`
-- **Default:** `random(3000, 8999)`
+- **类型：** `number`
+- **可选：** `true`
+- **默认值：** `random(3000, 8999)`
 
 配置 Rsdoctor 服务的端口。
 
@@ -267,9 +267,9 @@ Rsdoctor 报告输出目录，默认是构建产物输出目录。
 
 ### supports
 
-- **Type:** [Supports Types](#supports-types)
-- **Optional:** `true`
-- **Default:** `undefined`
+- **类型：** [Supports Types](#supports-types)
+- **可选：** `true`
+- **默认值：** `undefined`
 
 该选项是配置 Rsdoctor 是否开启某些细节特性分析能力支持的，例如：是否开启对 BannerPlugin 的兼容能力。
 
@@ -289,15 +289,15 @@ type ISupport = {
 开启 BannerPlugin 分析时，请勿在生产版本中使用 Rsdoctor。
 :::
 
-- default: true.
-- type: boolean.
+- **类型：** `boolean`
+- **默认值：** `true`
 
 如果开启 `supports.banner` 则会开启 Rsdoctor 对 BannerPlugin 的兼容逻辑。详细请看：[支持 BannerPlugin](../../guide/usage/bundle-size#%E6%94%AF%E6%8C%81-bannerplugin)
 
 #### generateTileGraph
 
-- default: true. 在 rspack 中默认值是 false。
-- type: boolean.
+- **默认值：** 使用 Rspack 时默认值是 `false`，否则为 `true`
+- **类型：** `boolean`
 
 是否开启生成瓦片图的能力，影响是 Bundle Size 页面中是否有 `webpack-bundle-analyzer` 的瓦片图。
 
@@ -308,8 +308,8 @@ type ISupport = {
 />
 #### parseBundle
 
-- default: true.
-- type: boolean.
+- **类型：** `boolean`
+- **默认值：** `true`
 
 在部分大型仓库中，反解 Bundle 解析执行耗时过大，这是因为 Parse Bundle 的分析利用了 AST 解析与处理。当产物文件过多时，耗时也会增加。如果不需要此功能，可以通过 `supports.parseBundle` 配置进行选择性关闭。示例如下：
 

package/docs/zh/guide/more/faq.mdx

@@ -14,7 +14,7 @@ new RsdoctorRspackPlugin({
 
 ## Loader 耗时数据不准？
 
-Rsdoctor 提供的 Loader 耗时时间是**预估耗时**，为什么没法统计到准确耗时？是因为我们知道 Loader 执行可能是**异步**函数也可能是**同步**函数，同时，构建器会**并行执行多个**不冲突的 Loader 函数，其中 **JS 是单线程**的，多个 Loader 函数均可能**抢占当前的任务队列**，同时 Loader 函数内的**异步逻辑没法识别**，导致单个 Loader 函数在执行过程中，**可能横跨**多个其他 Loader 的执行过程，所以会存在如下图所示的三种 case：
+Rsdoctor 提供的 Loader 耗时时间是**预估耗时**，为什么没法统计到准确耗时？是因为我们知道 Loader 执行可能是**异步**函数也可能是**同步**函数，同时，打包工具会**并行执行多个**不冲突的 Loader 函数，其中 **JS 是单线程**的，多个 Loader 函数均可能**抢占当前的任务队列**，同时 Loader 函数内的**异步逻辑没法识别**，导致单个 Loader 函数在执行过程中，**可能横跨**多个其他 Loader 的执行过程，所以会存在如下图所示的三种 case：
 
 <img
   src="https://assets.rspack.dev/others/assets/rsdoctor/loader-cases.jpeg"

package/docs/zh/guide/rules/rules.mdx

@@ -8,7 +8,7 @@
 
 :::
 
-### [E1001] Duplicate Packages
+### [E1001] Duplicate packages
 
 #### 规则详情
 
@@ -94,7 +94,7 @@ enum CheckVersion {
 
 点击 「**More**」可以查看对应规则解释。
 
-### [E1002] Cross Chunks Package
+### [E1002] Cross chunks package
 
 跨 Chunks 的重复包规则能够扫描**不同 `chunks` 中的重复包**。这些重复包也有可能导致打包代码冗余，具体还要看业务逻辑及冗余代码大小。
 
@@ -108,7 +108,7 @@ enum CheckVersion {
 
 可查看 [[E1002] Cross Chunks Packages](../more/rules)
 
-### [E1003] Loader Performance Optimization
+### [E1003] Loader performance optimization
 
 通过该模块可以比较直观的看到我们项目在编译方面的一些预警信息，有助于我们可以更进一步优化项目的编译性能。
 
@@ -142,7 +142,7 @@ interface Config {
 }
 ```
 
-### [E1004] ECMA Version Check
+### [E1004] ECMA version check
 
 该规则用于检测不兼容的高级语法。在规则扫描时，优先使用 `browserslist` 的配置；如果未配置 `browserslist`，则需要手动进行检测，示例如下：
 
@@ -202,7 +202,7 @@ type CheckSyntaxOptions = {
 
 更多 `ECMA Version Check` 配置请参考 [ECMA Version Check Options](https://github.com/rspack-contrib/rsbuild-plugin-check-syntax?tab=readme-ov-file#options)
 
-### [E1005] Default Import Check
+### [E1005] Default import check
 
 通常，Rspack 会自动兼容不同类型的模块，但在某些情况下，兼容性操作可能会失败。例如，当使用 `Default Import` 导入一个 `cjs` 模块时，如果该模块没有兼容的语句（如 `exports.default`），则会出现问题。
 

package/docs/zh/guide/start/cli.mdx

@@ -96,7 +96,7 @@ import { execute } from '@rsdoctor/cli';
 
 **execute()**
 
-`execute` 异步函数是 Rsdoctor CLI 的执行函数，通过调用 `execute` 函数就会自动解析 [process.argv](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processargv)，然后调用不同的命令。
+`execute` 异步函数是 Rsdoctor CLI 的执行函数，通过调用 `execute` 函数就会自动解析 [process.argv](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processargv)，然后调用不同的命令。
 
 **execute('analyze', \{...\})**
 

package/docs/zh/guide/start/quick-start.mdx

@@ -15,10 +15,10 @@ import { PackageManagerTabs } from '@theme';
 ### Webpack 项目
 
 :::tip
-不支持 Webpack 4 项目。
+Rsdoctor 仅支持 webpack >= 5。
 :::
 
-基于 Webpack 的项目，安装以下依赖：
+基于 webpack 的项目，安装以下依赖：
 
 <PackageManagerTabs command="add @rsdoctor/webpack-plugin -D" />
 

package/docs/zh/guide/usage/bundle-size.mdx

@@ -19,7 +19,7 @@
 
 - **`Assets`**：资源是对图像、字体、媒体和其他文件类型的统称，是最终存在于输出文件夹内的文件，同时，每个 Chunk 都有对应的 [Assets 资源](https://webpack.js.org/concepts/under-the-hood/#chunks)。
 - **`Module`**：一个或多个 Module 组合成了 Chunk。有关 Module 类型的详细信息，请参阅 [Rspack Modules](https://www.rspack.dev/api/modules.html) 和 [Webpack Modules](https://webpack.js.org/concepts/modules/#what-is-a-webpack-module)。
-- **`Bundle Size`**：资源产物的最终打包大小，这是构建器处理后的最终大小。
+- **`Bundle Size`**：资源产物的最终打包大小，这是打包工具处理后的最终大小。
 - **`Module Bundled Source & Size`**：**Module Parsed Source** 是指 **Module** 在打包产物中的最终代码片段，**Module Parsed Size** 是指 **Module** 在打包产物中的最终代码片段的大小。
 - **`Package Count`**：第三方包的数量。
 - **`Initial Chunk`**: **initial(初始化)** 是入口起点的主 Chunk，该 chunk 包含入口起点指定的所有模块及其依赖项，与「**按需加载**」的 **Chunk** 资源不同。
@@ -140,17 +140,16 @@
 
 Rsdoctor 兼容了对 BannerPlugin 这种添加代码的逻辑，但因为 Rsdoctor 需要添加标记代码，所以没有默认开启，以下两种情况会开启 Rsdoctor BannerPlugin 能力：
 
-1. 项目在 `rspack.config.j|ts` 或 `webpack.config.j|ts` 中使用了 BannerPlugin；
+1. 项目在 `rspack.config.(js|ts)` 或 `webpack.config.(js|ts)` 中使用了 BannerPlugin；
 
-2. 通过 Rsdoctor options 配置 supports.banner 来开启：
+2. 通过 Rsdoctor options 配置 `supports.banner` 来开启：
 
 ```ts
-new RsdoctorRspackPlugin (
+new RsdoctorRspackPlugin({
   supports: {
-    banner: true
-  }
-)
-
+    banner: true,
+  },
+});
 ```
 
 - 注：如果开启了 `drop_console` 将会影响 Rsdoctor 对 BannerPlugin 的分析，所以可以在 `RSDOCTOR = true` 时，关闭 `drop_console`。

package/docs/zh/guide/usage/compile-overall.mdx

@@ -19,12 +19,12 @@
 
 以下是卡片内每个阶段名词的含义以及代码实现：
 
-| 阶段名称                                 | 描述说明                                         | 代码实现                                                                                                                                                                                                            |
-| ---------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| <b><i>Bootstrap -> BeforeCompile</i></b> | 代表项目从启动到开始编译之前的耗时               | <ul><li>`Webpack` or `Rspack` 项目中：在 **compiler.hooks.beforeCompile** 被调用时上报 [process.uptime()](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processuptime) 作为<b>本阶段耗时</b></li></ul> |
-| <b><i>Compile</i></b>                    | 代表项目的整个编译耗时                           | <ul><li>`Webpack` or `Rspack` 项目中：在 **compiler.hooks.beforeCompile** 被调用时的时间点作为<b>开始时间</b>，在 **compiler.hooks.afterCompile** 被调用时的时间点作为<b>结束时间</b></li></ul>                     |
-| <b><i>AfterCompile -> Done</i></b>       | 代表编译结束到整个流程结束的耗时                 | <ul><li>`Webpack` or `Rspack` 项目中：在 **compiler.hooks.afterCompile** 被调用时的时间点作为<b>开始时间</b>，在 **compiler.hooks.done** 被调用时的时间点作为<b>结束时间</b></li></ul>                              |
-| <b><i>Minify</i></b>                     | 绝大部分情况下，代表项目编译流程内文件压缩的耗时 | <ul><li>`Webpack` or `Rspack` 项目中：统计 **compilation.hooks.optimizeChunkAssets** 和 **compilation.hooks.processAssets** 每次<b>调用时间之和</b></li></ul>                                                       |
+| 阶段名称                                 | 描述说明                                         | 代码实现                                                                                                                                                                              |
+| ---------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| <b><i>Bootstrap -> BeforeCompile</i></b> | 代表项目从启动到开始编译之前的耗时               | <ul><li>在 **compiler.hooks.beforeCompile** 被调用时上报 [process.uptime()](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processuptime) 作为<b>本阶段耗时</b></li></ul> |
+| <b><i>Compile</i></b>                    | 代表项目的整个编译耗时                           | <ul><li>在 **compiler.hooks.beforeCompile** 被调用时的时间点作为<b>开始时间</b>，在 **compiler.hooks.afterCompile** 被调用时的时间点作为<b>结束时间</b></li></ul>                     |
+| <b><i>AfterCompile -> Done</i></b>       | 代表编译结束到整个流程结束的耗时                 | <ul><li>在 **compiler.hooks.afterCompile** 被调用时的时间点作为<b>开始时间</b>，在 **compiler.hooks.done** 被调用时的时间点作为<b>结束时间</b></li></ul>                              |
+| <b><i>Minify</i></b>                     | 绝大部分情况下，代表项目编译流程内文件压缩的耗时 | <ul><li>统计 **compilation.hooks.optimizeChunkAssets** 和 **compilation.hooks.processAssets** 每次<b>调用时间之和</b></li></ul>                                                       |
 
 ## 使用说明
 
@@ -56,7 +56,7 @@
 
 该部分可以查看导航栏 「Compile Analysis」-> 「Loader Analysis」-> [**Loader Timeline**](./loaders-timeline.mdx) 来查看 Loader 编译耗时时序图。
 
-### AfterCompile -> Done 耗时详情
+### AfterCompile -> done 耗时详情
 
 通过**点击 `AfterCompile -> Done` 阶段后的数据**会在页面中弹出一个浮层，其内容如下图所示：
 

package/docs/zh/guide/usage/project-overall.mdx

@@ -18,7 +18,7 @@
 | <b><i>errors</i></b>  | 代表 Rsdoctor 在当次运行中检测出的 **error** 级别的规则                                                                 |
 | <b><i>warns</i></b>   | 代表 Rsdoctor 在当次运行中检测出的 **warn** 级别的规则                                                                  |
 | <b><i>webpack</i></b> | 代表当次运行时获取到的 Webpack 版本                                                                                     |
-| <b><i>cwd</i></b>     | 代表当次运行时的进程执行目录，即 [process.cwd()](https://nodejs.org/dist/latest-v18.x/docs/api/process.html#processcwd) |
+| <b><i>cwd</i></b>     | 代表当次运行时的进程执行目录，即 [process.cwd()](https://nodejs.org/dist/latest-v22.x/docs/api/process.html#processcwd) |
 | <b><i>cpu</i></b>     | 代表 cpu 信息                                                                                                           |
 | <b><i>memory</i></b>  | 代表当次运行时的 memory 信息                                                                                            |
 | <b><i>node</i></b>    | 代表 [Node.js](https://nodejs.org/) 版本号                                                                              |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rsdoctor/docs",
-  "version": "1.0.0-beta.3",
+  "version": "1.0.0-rc.0",
   "repository": {
     "type": "git",
     "url": "https://github.com/web-infra-dev/rsdoctor",
@@ -30,7 +30,7 @@
     "rspress-plugin-font-open-sans": "^1.0.0",
     "rspress-plugin-sitemap": "^1.1.1",
     "typescript": "^5.2.2",
-    "@rsdoctor/types": "1.0.0-beta.3"
+    "@rsdoctor/types": "1.0.0-rc.0"
   },
   "dependencies": {
     "@rstack-dev/doc-ui": "1.7.2",