@rsdoctor/docs 1.0.0-beta.3 → 1.0.0

package/README.md

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

package/docs/en/blog/release/release-note-0_1.mdx

@@ -23,11 +23,11 @@ Rsdoctor is a one-stop build analysis tool for Rspack and Webpack. It allows for
 - **Compilation Visualization**: Rsdoctor visualizes the compilation behavior and time consumption, making it easy to view build issues.
 - **Multiple Analysis Capabilities**: Rsdoctor supports build artifact, build-time analysis, and anti-degradation capabilities:
   - Build artifact support for resource lists and module dependencies, etc.
-  - Build-time analysis supports Loader, Plugin, and Resolver building process analysis, including: Rspack's builtin:swc-loader.
+  - Build-time analysis supports Loader, Plugin, and Resolver building process analysis, including Rspack's builtin loaders.
   - Build rules support duplicate package detection and ES Version Check, etc.
-  - Currently, bundle Diff capabilities are also available.
+  - Currently, bundle diff capabilities are also available.
 - **Support Custom Rules**: In addition to built-in build scan rules, Rsdoctor also supports users adding custom component scan rules based on the build data of Rsdoctor.
-- **Framework-Independent**: Rsdoctor support all projects built on Webpack or Rspack.
+- **Framework-Independent**: Rsdoctor support all projects built on Rspack or webpack.
 
 ## 🛠️ Introduction
 
@@ -48,7 +48,7 @@ Provides corresponding data and analysis functions for **Loaders, Plugins, and M
 
 #### Loader analysis
 
-- This module mainly provides the function of data analysis such as input and output, estimated time consumption, and parameters within **Rspack or Webpack Loaders**.
+- This module mainly provides the function of data analysis such as input and output, estimated time consumption, and parameters within **Rspack or webpack Loaders**.
 
 <div style={{ display: 'flex' }}>
   <img

package/docs/en/blog/release/release-note-0_3.mdx

@@ -78,7 +78,8 @@ export default {
 
 ## Support for banner plugin
 
-Both Rspack and Webpack support the BannerPlugin, which is an built-in plugin that allows you to add specific content at the top or bottom of the generated chunks. The added code will affect the parsing capability of the bundle.
+Both Rspack and webpack support the BannerPlugin, which is an built-in plugin that allows you to add specific content at the top or bottom of the generated chunks. The added code will affect the parsing capability of the bundle.
+
 Therefore, Rsdoctor has added support for the Banner Plugin.
 
 Please refer to [Support for BannerPlugin](/guide/usage/bundle-size#support-for-bannerplugin)

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/blog/topic/loader-optimization.mdx

@@ -3,7 +3,7 @@
 import NextSteps from '@components/NextSteps';
 import Step from '@components/Step';
 
-Optimizing loaders is a common way to improve the performance of Rspack or Webpack compilation. In most cases, besides replacing the loader with a faster one, we can also reduce execution by setting [module.rule.exclude](https://webpack.js.org/configuration/module/#ruleexclude) for the loader.
+Optimizing loaders is a common way to improve the performance of Rspack or webpack compilation. In most cases, besides replacing the loader with a faster one, we can also reduce execution by setting [module.rule.exclude](https://webpack.js.org/configuration/module/#ruleexclude) for the loader.
 
 Rsdoctor provides two core modules, [Loader Overall](/guide/usage/loaders-timeline) and [Loader Analysis](/guide/usage/loaders-analysis), to help you optimize based on the loader's invocation information.
 

package/docs/en/config/options/options.mdx

@@ -175,7 +175,7 @@ Therefore, **the default configuration enables bundle analysis capabilities and
 
 #### RsdoctorWebpackPluginFeatures
 
-`features` type：
+`features` type:
 
 import Features from '@en/shared/features.md';
 
@@ -183,7 +183,7 @@ import Features from '@en/shared/features.md';
 
 #### RsdoctorRspackPluginFeatures
 
-`features` type：
+`features` type:
 
 import FeaturesRspack from '@en/shared/features-rspack.md';
 

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
@@ -68,45 +68,3 @@ When using Rsdoctor to analyze the compilation time of Rspack projects, you may
 - Reason: The loader in [CssExtractRspackPlugin](https://rspack.dev/plugins/rspack/css-extract-rspack-plugin) asynchronously calls other loaders during the pitch phase and waits for the callback results after these loaders execute. Therefore, the time taken by CssExtractRspackPlugin actually includes the execution time of other loaders and idle time.
 
 <img src="https://assets.rspack.dev/rsdoctor/css-extract-loader.png" />
-
-## Next.js
-
-### Issue with Next.js project report page
-
-Initialize the RsdoctorWebpackPlugin plugin in the [Webpack Config](https://nextjs.org/docs/app/api-reference/next-config-js/webpack) of `next.config.js`.
-
-However, in Next.js, when Rsdoctor is enabled and the **build command** is executed, the report server started by Rsdoctor will be disconnected. Therefore, if you need to reopen the report, you can use **[@rsdoctor/cli](../start/cli.mdx)** without performing the build operation.
-
-For example, if the build artifact of Rsdoctor is located at the path `.next/.rsdoctor/manifest.json`, you can open the report page by executing the following command:
-
-```bash
-npx @rsdoctor/cli analyze --profile .next/.rsdoctor/manifest.json
-
-```
-
-### Loader analysis with rule override is not supported in Next.js
-
-- Rsdoctor Loader logic: Since Rsdoctor modifies the Loader Rules, Rsdoctor wraps the Module in a Proxy to support Loader logic with rule override.
-
-- Next.js specific logic: In Next.js, the LoaderContext adds the currentTraceSpan property, which is obtained from the value retrieved using the Module as the key. However, since Rsdoctor wraps the Module in a Proxy (referred to as ProxyModule), retrieving the value using ProxyModule as the key will result in no value being obtained.
-
-Based on the above reason, Rsdoctor does not wrap the Module in a Proxy in Next.js projects, which means it does not support Loader analysis with rule override. If you encounter Loader errors, you need to configure the **[features](../../config/options/options#features)** parameter to disable **Loader** analysis. You can use the following configuration:
-
-```js title="next.config.js"
-const { RsdoctorWebpackPlugin } = require('@rsdoctor/webpack-plugin');
-
-module.exports = {
-  // ...
-  webpack: (config, { isServer }) => {
-    config.plugins.push(
-      new RsdoctorWebpackPlugin({
-        // 插件选项
-        features: ['bundle', 'plugins'],
-      }),
-    );
-    return config;
-  },
-};
-```
-
-- **Options:** The plugin provides some configurations, please refer to [Options](../../config/options/options).

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/intro.mdx

@@ -3,20 +3,20 @@
 ## 💡 What is Rsdoctor?
 
 - Rsdoctor is a one-stop tool for diagnosing and analyzing the build process and build artifacts.
-- Rsdoctor is a tool that supports Webpack and Rspack build analysis.
+- Rsdoctor is a tool that supports Rspack and webpack build analysis.
 - Rsdoctor is an analysis tool that can display the time-consuming and behavioral details of the compilation.
-- Rsdoctor is a tool that provides bundle Diff and other anti-degradation capabilities simultaneously.
+- Rsdoctor is a tool that provides bundle diff and other anti-degradation capabilities simultaneously.
 
 ## 🔥 Features
 
 - **Compilation Visualization**: Rsdoctor visualizes the compilation behavior and time consumption, making it easy to view build issues.
 - **Multiple Analysis Capabilities**: Rsdoctor supports build artifact, build-time analysis, and anti-degradation capabilities:
   - Build artifact support for resource lists and module dependencies, etc.
-  - Build-time analysis supports Loader, Plugin, and Resolver building process analysis, including: Rspack's builtin:swc-loader.
+  - Build-time analysis supports Loader, Plugin, and Resolver building process analysis, including Rspack's builtin loaders.
   - Build rules support duplicate package detection and ES Version Check, etc.
-  - Currently, bundle Diff capabilities are also available.
+  - Currently, bundle diff capabilities are also available.
 - **Support Custom Rules**: In addition to built-in build scan rules, Rsdoctor also supports users adding custom component scan rules based on the build data of Rsdoctor.
-- **Framework-Independent**: Rsdoctor support all projects built on Webpack or Rspack.
+- **Framework-Independent**: Rsdoctor support all projects built on Rspack or webpack.
 
 ## 🛠️ Introduction
 
@@ -36,7 +36,7 @@ Provides corresponding data and analysis functions for **Loaders, Plugins, and M
 
 #### Loader analysis
 
-- This module mainly provides the function of data analysis such as input and output, estimated time consumption, and parameters within Rspack / Webpack Loaders.
+- This module mainly provides the function of data analysis such as input and output, estimated time consumption, and parameters within Rspack or webpack loaders.
 
 <img
   src="https://assets.rspack.dev/others/assets/rsdoctor/loader-timeline-overall.png"

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:
 
@@ -75,41 +75,70 @@ export default {
 - **Options:** The plugin provides some configurations, please refer to [Options](../../config/options/options).
 
 :::tip
-For projects using Modern.js Webpack mode, please register the `RsdoctorWebpackPlugin` plugin through [tools.webpack](https://modernjs.dev/configure/app/tools/webpack).
+For projects using Modern.js's webpack mode, please register the `RsdoctorWebpackPlugin` plugin through [tools.webpack](https://modernjs.dev/configure/app/tools/webpack).
 :::
 
 ### Next.js Framework
 
-Initialize the RsdoctorWebpackPlugin plugin in the [Webpack Config](https://nextjs.org/docs/app/api-reference/next-config-js/webpack) of `next.config.mjs`.
+Initialize the RsdoctorWebpackPlugin plugin in the [Webpack Config](https://nextjs.org/docs/app/api-reference/next-config-js/webpack) of `next.config.ts`.
 
-```ts title="next.config.mjs"
+```ts title="next.config.ts"
+import type { NextConfig } from 'next';
 import { RsdoctorWebpackPlugin } from '@rsdoctor/webpack-plugin';
 
-export default {
-  // ...
-  webpack: (config, { isServer }) => {
-    config.plugins.push(
-      new RsdoctorWebpackPlugin({
-        // plugin options
-      }),
-    );
-
+const nextConfig: NextConfig = {
+  /* config options here */
+  webpack: (config) => {
+    if (config.name === 'client') {
+      config.plugins.push(
+        new RsdoctorWebpackPlugin({
+          disableClientServer: true,
+        }),
+      );
+    } else if (config.name === 'server') {
+      config.plugins.push(
+        new RsdoctorWebpackPlugin({
+          disableClientServer: true,
+          output: {
+            reportDir: './.next/server',
+          },
+        }),
+      );
+    }
     return config;
   },
 };
+
+export default nextConfig;
 ```
 
-- **Options:** The plugin provides some configurations, please refer to [Options](../../config/options/options).
+- **Options:** The plugin provides some configuration options, please refer to [Options](../../config/options/options).
 
-#### 📢 Next.js project notice
+#### 📢 Note for Next.js Projects
 
-1. Next.js Project Reporting Page Issues
+Since Next.js closes the terminal service after the `build` execution is completed, the report page server run by Rsdoctor during the build process will also be shut down. At this point, you can reopen the report page using [@rsdoctor/cli](/guide/start/cli) without having to execute the build operation again.
 
-For more details, see: [FAQ](../more/faq#nextjs)
+- First, install [@rsdoctor/cli](/guide/start/cli):
 
-2. Loader Analysis with Rules Overriding Not Supported in Next.js
+import { PackageManagerTabs } from '@theme';
 
-For more details, see: [FAQ](../more/faq#nextjs)
+<PackageManagerTabs command="add @rsdoctor/cli -D" />
+
+- Second, add the following scripts commands to **package.json**, executing **client:rsdoctor** or **server:rsdoctor** can open the report for the corresponding builder:
+
+```ts
+  "scripts": {
+    "client:rsdoctor": "rsdoctor analyze --profile .next/.rsdoctor/manifest.json",
+    "server:rsdoctor": "rsdoctor analyze --profile .next/server/chunks/.rsdoctor/manifest.json"
+  }
+```
+
+For example, if Rsdoctor's build artifacts are located at the `.next/server/chunks/.rsdoctor/manifest.json` path, you can open the report page by executing the following command:
+
+```bash
+rsdoctor analyze --profile .next/server/chunks/.rsdoctor/manifest.json
+
+```
 
 ### Vue project
 
@@ -141,7 +170,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,13 +19,13 @@ 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".
   - For more information about Initial Chunk, please refer to [Initial Chunk Introduction](https://webpack.js.org/concepts/under-the-hood/#chunks).
 - **`Duplicate Packages`**: Duplicate third-party packages bundled into the project. Excludes third-party packages that are not bundled into the artifact. Please refer to [Duplicate Packages](/guide/usage/bundle-alerts).
-- **`Concatenated Module`**: A concatenated module is a technique that combines multiple modules into one closure during packaging. In the past, Webpack would package each module into a separate closure, and this encapsulation function would cause slower execution of JavaScript in the browser. Optimization can be achieved by enabling the [`optimization.concatenateModules`](https://webpack.js.org/plugins/module-concatenation-plugin/#root) parameter.
+- **`Concatenated Module`**: A concatenated module is a technique that combines multiple modules into one closure during packaging. In the past, Rspack would package each module into a separate closure, and this encapsulation function would cause slower execution of JavaScript in the browser. Optimization can be achieved by enabling the [`optimization.concatenateModules`](https://webpack.js.org/plugins/module-concatenation-plugin/#root) parameter.
 
 ## Bundle overview
 
@@ -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.
 
@@ -144,22 +144,22 @@ Click the **"Bundle Analyzer Graph"** button on the **"Bundle Size"** page to vi
 When enabling the BannerPlugin analysis, do not use Rsdoctor in the production version.
 :::
 
-Both Rspack and Webpack support the [BannerPlugin](https://www.rspack.dev/plugins/webpack/banner-plugin#bannerplugin), which is a built-in plugin that allows you to add specific content at the top or bottom of the generated chunks.
+Both Rspack and webpack support the [BannerPlugin](https://www.rspack.dev/plugins/webpack/banner-plugin#bannerplugin), which is a built-in plugin that allows you to add specific content at the top or bottom of the generated chunks.
+
 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/plugins-analysis.mdx

@@ -2,7 +2,7 @@
 
 ## Overview
 
-In the **Rsdoctor** `Compile Analysis` secondary page `Plugins Analysis`, we can see the invocation data of all **Compiler Hooks** and **Compilation Hooks** used by the current Rspack or Webpack project. The content is shown in the following figure:
+In the **Rsdoctor** `Compile Analysis` secondary page `Plugins Analysis`, we can see the invocation data of all **Compiler Hooks** and **Compilation Hooks** used by the current Rspack or webpack project. The content is shown in the following figure:
 
 <img
   src="https://assets.rspack.dev/others/assets/rsdoctor/plugins-analysis-overall.png"
@@ -29,7 +29,7 @@ The meanings of the fields in the data statistics table on the page are as follo
 
 ### View bundler config
 
-If we need to view the Rspack or Webpack configuration of the project, we can click on `View Bundler Config` in the upper right corner of the card. A floating layer will pop up, which contains the serialized **Bundler Config**, as shown in the following figure:
+If we need to view the Rspack or webpack configuration of the project, we can click on `View Bundler Config` in the upper right corner of the card. A floating layer will pop up, which contains the serialized **Bundler Config**, as shown in the following figure:
 
 <img
   src="https://assets.rspack.dev/others/assets/rsdoctor/plugins-analysis-config.png"