@rsdoctor/docs 0.0.0-next-20240620044732

package/docs/en/guide/usage/loaders-analysis.mdx

@@ -0,0 +1,72 @@
+# Loaders Analysis
+
+**Rsdoctor** provides the `Loader Analysis` module, which mainly provides statistics on Loaders at the **directory and file level**. It helps you analyze the compilation of **folders** and **individual files** by Loaders.
+
+Click on the navigation bar **"Compile Analysis"** -> **"Loader Analysis"** option to view the compilation analysis report. Of course, this page will only display the features if the `loader` analysis capability is enabled [features](/config/options/options).
+
+## Overview
+
+Firstly, in this module, you can directly see the file tree structure of all files processed by Loaders, as shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-anlaysis-all.png"
+  width="600px"
+  style={{ margin: 'auto' }}
+/>
+
+In the **filter search box** at the top, you can filter Loaders and search for file names. After entering the name, the file tree dynamically displays the matching files, making it easier to locate the files you want to query.
+
+In the file tree structure below, there are two interactive forms to obtain different data information:
+
+- **Clicking on a directory**: Displays **Loader data for the file directory**.
+- **Clicking on a file**: Displays **detailed Loader information for the individual file**.
+
+The corresponding details will be explained in the following paragraphs.
+
+## Loader Data for File Directories
+
+By **clicking on a selected directory**, you can see the **time statistics of all Loaders in the selected directory** ([estimated time consumption](../../guide/more/faq#loader-time-consuming-data-is-inaccurate)) on the right side of the file tree. The content of the "Statistics of xxx" card is shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-anlaysis-table.png"
+  width="300px"
+  height="400px"
+  style={{ margin: 'auto' }}
+/>
+
+Here are the main information we can obtain:
+
+- The number of **files processed** and the **estimated time consumption** for an **individual Loader** in the selected directory.
+- The number of **files processed** and the **estimated time consumption** for **all Loaders** in the selected directory.
+
+Usually, we can select some **third-party library directories** within `node_modules` and then determine whether it is necessary to set [module.rule.exclude](https://webpack.js.org/configuration/module/#ruleexclude) for this directory based on the Loader's time consumption information. This helps reduce the processing time of common Loaders like `babel-loader`.
+
+If it is a third-party library with **advanced ES syntax** or a package within the **workspace**, we need to make more granular decisions at the individual file level based on the content in the next paragraph to optimize Loader performance.
+
+## Loader Details for Individual Files
+
+By **clicking on a file**, a modal will appear with the following content:
+
+- "**Left section**": A list of all **executed Loaders** for the clicked file and the **time consumption** of each Loader for compiling the file.
+
+- "**Right section**": Information about the **input, output**, and **parameter data** of the selected Loader at the time of invocation.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-analysis-code-change.png"
+  width="600px"
+  style={{ margin: 'auto' }}
+/>{' '}
+
+- **Parameter Data**: Click on "**show more**" or the expand button in the top left corner to view the corresponding parameter information.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-analysis-options.png"
+  width="600px"
+  style={{ margin: 'auto' }}
+/>{' '}
+
+As shown in the image, we can obtain the following information about the **target file**:
+
+- All the Loaders it has gone through.
+- The **parameter data** on the [**Loader Context**](https://webpack.js.org/api/loaders/#the-loader-context).
+- The input and output of the Loader.

package/docs/en/guide/usage/loaders-timeline.mdx

@@ -0,0 +1,68 @@
+# Loaders Timeline
+
+## Overview
+
+By clicking on the "Compile Analysis" -> "Loader Analysis" option in the navigation bar of **Rsdoctor**, we can see the **execution timeline** of all loaders in the current project. Please note that this page requires the `loader` analysis capability to be enabled in order to display the [features](/config/options/options). The content of this page is shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-overall.png"
+  width="700"
+  style={{ margin: 'auto' }}
+/>
+
+## Glossary
+
+The fields in the chart on the page have the following meanings:
+
+| Term                                 | Description                                                                                                               |
+| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
+| <b><i>files</i></b>                  | Represents the **total number of files** processed by the loader                                                          |
+| <b><i>files(node_modules)</i></b>    | Represents the number of files processed by the loader within `node_modules`                                              |
+| <b><i>files(outside the cwd)</i></b> | Represents the number of files processed by the loader outside of the `cwd`                                               |
+| <b><i>duration</i></b>               | Represents the **estimated time** taken by the loader to execute                                                          |
+| <b><i>start(min)</i></b>             | Represents the **earliest start time** among all the data of the loader                                                   |
+| <b><i>end(max)</i></b>               | Represents the **latest end time** among all the data of the loader                                                       |
+| <b><i>isPitch</i></b>                | Represents whether the loader execution is a [pitch](https://webpack.js.org/api/loaders/#pitching-loader) function or not |
+| <b><i>filepath</i></b>               | Represents the **file path** received by the loader                                                                       |
+| <b><i>start</i></b>                  | Represents the **start time** of the loader execution                                                                     |
+| <b><i>end</i></b>                    | Represents the **end time** of the loader execution                                                                       |
+
+## Usage
+
+In the **Loaders Timeline**, the **left Y-axis** represents the **loader names**, while the **top X-axis** corresponds to **time (hour:minute:second)**. We can use the zoom feature and hover over the chart to view more detailed information about loader invocations.
+
+There are two selector at the top of the page, where you can enter the **Loaders** or **Files** you want to filter, and the timeline chart will be displayed based on the filtered content.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-overall.png"
+  width="700"
+  style={{ margin: 'auto' }}
+/>
+
+### Viewing Overall Loader Information
+
+If we want to view the **summary of all data** for a single loader, we can hover over the position shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-loader-timeline.png"
+  width="700"
+  style={{ margin: 'auto' }}
+/>
+
+At this point, we can see the **summary of all invocations** within a single loader (refer to the [Glossary](#glossary) for field definitions), as shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-loader-card.png"
+  width="700"
+  style={{ margin: 'auto' }}
+/>
+
+### Viewing Individual Loader Invocation Information
+
+If we want to view the **information of a single invocation** for a loader, we can hover over any **colored stripe** within the position shown in the following image. At this point, we can see the **information of the current invocation** within a single loader (refer to the [Glossary](#glossary) for field definitions), as shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-loader-file.png"
+  width="700"
+  style={{ margin: 'auto' }}
+/>

package/docs/en/guide/usage/module-analysis.mdx

@@ -0,0 +1,58 @@
+# Module Dependency Analysis
+
+## Introduction
+
+**Rsdoctor** provides the `Module Imported Chain Analysis` module, which is mainly used to analyze the dependency tree of a specific module, i.e. the modules that depend on it, similar to [Webpack's stats.reasons](https://webpack.js.org/configuration/stats/#statsreasons).
+
+In this section, you can analyze the imported chain of a module. If you have the need to split the package or want to see why a certain module is being imported, you can quickly and clearly locate the reference chain through the `Module Imported Chain Analysis`.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/module-analysis-tree.png"
+  width="600px"
+  style={{ margin: 'auto' }}
+/>
+
+### This Section’s Entry
+
+Clicking on an **Assets** in the **[Bundle Size](./bundle-size)** page will display the `「Module Tree」` on the right side. Each **Module** will have the following icon next to it, click on it to view the imported chain of that **Module**.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/module-analysis-entry.png"
+  height="300px"
+  width="440px"
+  style={{ margin: 'auto' }}
+/>
+
+### Glossary
+
+- **`Reasons`**: As the name suggests, it means the reasons why a `Module` exists. Reasons indicate which other `Module`s import this `Module`, and the entire `Reasons Tree` represents the upstream reference chain of this `Module`, including both direct and indirect parent `Module`s. [Similar to Webpack's stats.reasons.](https://webpack.js.org/configuration/stats/#statsreasons)
+- **`Dependencies`**: The `Module`s that this `Module` depends on.
+
+## Reasons Dependency Tree
+
+### Introduction
+
+The `Reasons Tree` displays the dependency chain of this `Module`, showing which other `Modules` directly or indirectly import it. In this dependency tree, you can view the `Bundled Size` of the `Modules` along the dependency chain. You can also click the right arrow `>` to navigate to the `Module Dependency Analysis` page for that specific `Module`.
+
+- **Parent-child relationship in the dependency tree**: The parent node file is the one that is depended upon by the child node file and is therefore bundled into the output. Similarly, the grandchild node file is depended upon by the child node and is bundled into the output, and so on.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/module-analysis-jump-icon.png"
+  width="700px"
+  style={{ margin: 'auto' }}
+/>
+
+- The `Usage` tag displays the purpose of various module tags.
+
+- The `Concatenated` tag:
+
+  - The `Concatenated` tag indicates that the module is a concatenated sub-module. Hover over it to see which main module it is aggregated into. This type of aggregated module cannot be further unpacked, so the specific `Bundled Size` cannot be determined, only the size of the entire concatenated module can be known.
+  - Glossary: A **concatenated module** is when multiple modules are promoted or **concatenated into a closure** during packaging. For an explanation of `Concatenated Module`, refer to the [Glossary](guide/usage/bundle-size#glossary).
+
+- The `!` tag, hover over it to display the detailed path of the module.
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/module-analysis-icons.png"
+  width="600px"
+  style={{ margin: 'auto' }}
+/>

package/docs/en/guide/usage/plugins-analysis.mdx

@@ -0,0 +1,43 @@
+# Plugin Analysis
+
+## 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:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/plugins-analysis-overall.png"
+  width={'600px'}
+  style={{ margin: 'auto' }}
+/>
+
+:::tip
+The plugin time will also calculate the internal plugin time of Rsdoctor.
+:::
+
+## Glossary
+
+The meanings of the fields in the data statistics table on the page are as follows:
+
+| Term                          | Description                                                                                               |
+| ----------------------------- | --------------------------------------------------------------------------------------------------------- |
+| <b><i>Plugin Tap Name</i></b> | Represents the name value when [.tap is called](https://github.com/webpack/tapable#hookhookmap-interface) |
+| <b><i>Hook</i></b>            | Represents the **hook name**                                                                              |
+| <b><i>calls</i></b>           | Represents the **number of times called**                                                                 |
+| <b><i>duration(total)</i></b> | Represents the **total time of all calls**                                                                |
+
+## Usage Instructions
+
+### 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:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/plugins-analysis-config.png"
+  width={'400px'}
+  style={{ margin: 'auto' }}
+/>
+
+## Reference Documentation
+
+- [**Rspack Hooks**](https://www.rspack.dev/api/plugin-api.html#beforecompile)
+- [**Webpack Hooks**](https://webpack.js.org/api/compilation-hooks/)

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

@@ -0,0 +1,51 @@
+# Project Overall
+
+## Overview
+
+In the main page of **Rsdoctor**, we can see a card named `Project Overall`, which provides information about the current project's **configuration, version, and alerts**. The content is shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/project-overall-1.jpg"
+  width="400px"
+  height="600px"
+  style={{ margin: 'auto' }}
+/>
+
+## Glossary
+
+| Term                  | Description                                                                                                                                                   |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| <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>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/)                                                                                               |
+| <b><i>yarn</i></b>    | Represents the version number of [Yarn](https://yarnpkg.com/), displayed as `Not Found` if not found                                                          |
+| <b><i>npm</i></b>     | Represents the version number of [npm](https://www.npmjs.com/)                                                                                                |
+| <b><i>pnpm</i></b>    | Represents the version number of [pnpm](https://pnpm.io/), displayed as `Not Found` if not found                                                              |
+
+## Usage
+
+### 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 top right corner of the card. A popup window will appear, containing the serialized [Bundler Config](https://webpack.js.org/configuration/), as shown in the following image:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/project-overall-config.jpg"
+  width="500px"
+  style={{ margin: 'auto' }}
+/>
+
+### errors / warns
+
+If the numbers displayed in the `errors` and `warns` sections of the card are greater than 0, we can click on them to view the corresponding details list. The following image shows an example using `warns`:
+
+<img
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/overall/project-overall-warning.jpg"
+  width="500px"
+  style={{ margin: 'auto' }}
+/>
+
+We can see the list of `warn` level alerts detected by Rsdoctor.

package/docs/en/guide/usage/resolver.mdx

@@ -0,0 +1,32 @@
+# Resolver Analysis
+
+:::tip
+
+- Resolve analysis capability is not currently supported in Rspack projects.
+
+- The Resolver analysis capability is disabled by default. To enable it, you can add `resolver` to the `features` array as shown in the example below. [features configuration](../../config/options/options).
+
+```js
+new rsdoctorWebpackPlugin({
+  features: [
+    'resolver',
+    // ...other features
+  ],
+});
+```
+
+:::
+
+In the **Rsdoctor** `Module Resolve` section, we can see all the source files in the current Webpack project. By **clicking on a file**, we can view information such as the **module paths** imported in that file, the **before and after resolution path comparison**, and the **resolution time**, as shown in the following image:
+
+<img src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/resolver.png" />
+
+## Glossary
+
+The fields in the data statistics table on the page are defined as follows:
+
+| Term                         | Description                                                     |
+| ---------------------------- | --------------------------------------------------------------- |
+| <b><i>Source Code</i></b>    | Represents the **source code** of the import statement          |
+| <b><i>Duration</i></b>       | Represents the **time taken** for resolution                    |
+| <b><i>Resolve Result</i></b> | Represents the **final path** after resolving the `Source Code` |

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

@@ -0,0 +1,85 @@
+# Compilation Diagnostic Rules
+
+Building diagnostic rules is similar to lint tools like `ESLint`, but with a difference. `ESLint` performs static code scanning and is independent of the build process. On the other hand, the code diagnostics here are closely related to the build process of `Rspack` or `Webpack`. It incorporates various internal parameters generated during the build process to assist in the analysis, such as ModuleGraph, internal markers for each module by Webpack, and runtime added after code transformation, and so on...
+
+If any issues are detected during the build process, they will be displayed in the CLI and the diagnostic summary webpage, as shown in the following image:
+
+<img
+  width="700"
+  style={{ margin: '10px auto' }}
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/rule-config-cli.png"
+/>
+
+<img
+  width="700"
+  style={{ margin: '10px auto' }}
+  src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/bundle/rule-config-1.png"
+/>
+
+## How to Use
+
+Using diagnostic rules is simple. They are configured under the `linter` option of the entire plugin, as shown in the following example:
+
+```ts
+import { RsdoctorWebpackPlugin } from '@rsdoctor/webpack-plugin';
+
+export default {
+  plugin: [
+    new RsdoctorWebpackPlugin({
+      linter: {
+        level: 'Error',
+        extends: [],
+        rules: {
+          'default-import-check': 'off',
+          'duplicate-package': [
+            'Error',
+            {
+              checkVersion: 'minor',
+              ignore: ['chalk', '@bable/runtime'],
+            },
+          ],
+        },
+      },
+    }),
+  ],
+};
+```
+
+The type of `linter`：
+
+```ts
+interface Options {
+  rules?: RulesMap;
+  level?: SeverityString;
+  extends?: ExtendRuleData[];
+}
+
+/**
+ * Validation Level
+ *   - When set to `'Warn'`, only rules with the category `'Warn'` will be executed
+ *   - When set to `'Error'`, all rules will be executed
+ */
+type SeverityString = 'Warn' | 'Error';
+
+/** Rule Level */
+type SeverityInput = SeverityString | 'off' | 'on';
+
+/** Rule Configuration */
+type RulesMap = Record<string, RuleConfigItem>;
+
+/** Individual Rule Configuration */
+type RuleConfigItem =
+  // Only severity level, which takes precedence over the rule's own configuration
+  | SeverityInput
+  // In the case of an array, the first item is the severity level, and the second item is the rule configuration
+  | [SeverityInput, unknown];
+```
+
+## Existing Internal Rules
+
+There are already three rules included in the existing diagnostic tool, which are:
+
+1. [[E1001] Duplicate Packages](./bundle-alerts#%E9%87%8D%E5%A4%8D%E7%AC%AC%E4%B8%89%E6%96%B9%E5%8C%85)
+2. [[E1002] Default Import Check](../more/rules)
+3. [[E1003] Loader Performance Optimization](../more/rules)
+4. [[E1004] ECMA Version Check](../more/rules)

package/docs/en/index.md

@@ -0,0 +1,38 @@
+---
+pageType: home
+
+hero:
+  name: Rsdoctor
+  text: Analyzer for Rspack & Webpack
+  tagline: Visualize the building process
+  actions:
+    - theme: brand
+      text: Introduction
+      link: /guide/start/intro
+    - theme: alt
+      text: Quick Start
+      link: /guide/start/quick-start
+  image:
+    src: https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/logo/rsdoctor.png
+    alt: Rsdoctor Logo
+
+features:
+  - title: Unlimited Framework
+    details: Rsdoctor support all projects built on Webpack or Rspack.
+    icon: 🛠️
+  - title: Compile’s Time
+    details: To display the compile execution time and process in the form of a timing diagram.
+    icon: 🚀
+  - title: Compile’s Actions
+    details: Visually view the compilation changes of each file in each loader.
+    icon: 🦄
+  - title: Bundle Analysis
+    details: Visually view the bundles & modules relationship, module reference relationship and repeated packages in detail.
+    icon: 🎯
+  - title: Bundle Diff
+    details: Through comparison, the deterioration and change of the product are found.
+    icon: 🎨
+  - title: Build Scan
+    details: Built-in build rule scanning, and also supports custom rules.
+    icon: 🔍
+---

package/docs/public/netlify.toml

@@ -0,0 +1,4 @@
+[[redirects]]
+from = "/*"
+to = "/404.html"
+status = 404

package/docs/zh/_meta.json

@@ -0,0 +1,17 @@
+[
+  {
+    "text": "指南",
+    "link": "/guide/start/intro",
+    "activeMatch": "/guide/"
+  },
+  {
+    "text": "配置",
+    "link": "/config/options/options",
+    "activeMatch": "/config/"
+  },
+  {
+    "text": "博客",
+    "link": "/blog/release/release-note-1",
+    "activeMatch": "/blog/"
+  }
+]

package/docs/zh/blog/_meta.json

@@ -0,0 +1,12 @@
+[
+  {
+    "type": "dir",
+    "name": "release",
+    "label": "Release 公告"
+  },
+  {
+    "type": "dir",
+    "name": "topic",
+    "label": "专题"
+  }
+]

package/docs/zh/blog/release/_meta.json

@@ -0,0 +1 @@
+["release-note-1"]

package/docs/zh/blog/release/release-note-1.mdx

@@ -0,0 +1,128 @@
+# Rsdoctor v0.1 发布公告
+
+<picture>
+  <img
+    alt="Rsdoctor Banner"
+    src="https://github.com/web-infra-dev/rsdoctor/assets/7237365/0f9d2e86-d919-451a-befa-fa84603a87cf"
+    style={{ margin: 'auto' }}
+  />
+</picture>
+
+我们很高兴地宣布 [Rsdoctor](https://rsdoctor.dev/) v0.1 发布了！
+
+Rsdoctor 是一个针对 Rspack 和 Webpack 的一站式构建分析工具，可以对构建时和构建产物进行详细分析，让构建过程变得可视化和透明。
+
+## 📌 定位
+
+**Rsdoctor** 是一个构建分析工具，用于分析基于 [Rspack](https://www.rspack.dev/) 和 [Webpack](https://webpack.js.org/) 构建的项目。它支持分析的项目包括：[Rsbuild](https://rsbuild.dev/zh/index)、[Create React App](https://create-react-app.dev/)、[Modern.js](https://modernjs.dev/) 等。
+
+![Position](https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/rsdoctor-position.png)
+
+## 🔥 特性
+
+- **编译可视化**：Rsdoctor 将编译行为及耗时进行可视化展示，方便开发同学查看构建问题。
+- **多种分析能力**：支持构建产物、构建时分析能力：
+  - 构建产物支持资源列表及模块依赖等。
+  - 构建时分析支持 Loader、Plugin、Resolver 构建过程分析。
+  - 支持 Rspack 的 builtin:swc-loader 分析。
+  - 构建规则支持重复包检测及 ES Version Check 检查等。
+- **支持自定义规则**：除了内置构建扫描规则外，还支持用户根据 Rsdoctor 的构建数据添加自定义构建扫描规则。
+- **框架无关**：支持所有基于 Webpack 或 Rspack 构建的项目。
+
+## 🛠️ 功能介绍
+
+### ⭐️ 概览
+
+- 概览页能够知道**项目配置、诊断信息、编译信息、产物情况**。
+
+![Overall](https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/start/overall.jpg)
+
+- 除了项目概览之外，我们还提供了诊断模块，分别用于编译诊断、重复包诊断等。如果你的编译、产物命中了我们定义的诊断规则，就会在工具首页出现对应的警示模块, **其中重复包可以查看到详细的引用路径**。
+
+![Overall-Alerts](https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/start/overall-alerts.jpg)
+
+### ⭐️ 编译分析
+
+面向 **Loaders、Plugins、Module Resolver** 提供了对应的数据与分析功能，来帮助你分析编译过程中的问题。
+
+#### Loader 分析
+
+- 该模块主要提供了 **Rspack** 或 **Webpack Loaders** 内的输入输出、预估耗时、参数等数据分析的功能。
+
+<div style={{ display: 'flex' }}>
+  <img
+    src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-timeline-overall.png"
+    width="55%"
+    style={{ margin: 'auto' }}
+  />
+  <img
+    src="https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/usage/compile/loader-anlaysis-all.png"
+    width="45%"
+    style={{ margin: 'auto' }}
+  />
+</div>
+
+#### Plugin 分析
+
+- 该模块主要拦截并收集了 Plugins 的调用次数、预估耗时等数据信息。
+
+<p>
+  <img
+    alt="bundle"
+    src={
+      'https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/start/compile-plugin.jpg'
+    }
+    width="600px"
+    style={{ margin: 'auto' }}
+  />
+</p>
+
+#### Resolver 分析
+
+- 该模块主要提供了项目内部单个文件中模块解析的路径数据以及预估耗时。Rspack 暂时未支持该模块。
+
+<p>
+  <img
+    alt="bundle"
+    src={
+      'https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/start/resolver.jpeg'
+    }
+    width="700px"
+    style={{ margin: 'auto' }}
+  />
+</p>
+
+### ⭐️ 产物分析
+
+- 我们在 **「Bundle Size」** 模块中，可以看到当前项目的产物数据信息概览，以及分析重复包引入的体积与上游依赖链路。
+
+- 此外，还可以通过 **「Bundle Analysis」** 模块来进一步分析当前产物中资源与模块关系，体积数据等信息，以及查看模块引入的原因。
+
+<p>
+  <img
+    alt="bundle"
+    src={
+      'https://lf3-static.bytednsdoc.com/obj/eden-cn/lognuvj/rsdoctor/docs/start/bundle-size.jpg'
+    }
+    width="700px"
+    style={{ margin: 'auto' }}
+  />
+</p>
+
+## 📚 快速上手
+
+你可以参考 [快速上手](/guide/start/quick-start) 来开始体验 **Rsdoctor**。
+
+## 💡 下一步
+
+**提升 Rsdoctor 构建分析效率**：目前开启 Rsdoctor 时会增加项目的构建耗时，下一步我们将抽离 Rsdoctor 的部分构建分析逻辑，并转化为 **Rust 插件**，内置到 Rspack 中，从而提升 Rsdoctor 的构建分析效率。
+
+## 致谢
+
+Rsdoctor 的一些实现参考了社区中杰出的项目，对他们表示感谢：
+
+- 借鉴了 [bundle-stats](https://github.com/relative-ci/bundle-stats/tree/master/packages/cli#readme) 对产物关系的分析逻辑。
+- 借鉴了 [webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer) 对产物模块拆解及分析逻辑。
+- [Statoscope](https://github.com/statoscope/statoscope/blob/master/README.md)是一个优秀的构建产物分析工具，Rsdoctor 在构建产物分析方面受到了它的启发。
+- [Webpack 团队和社区](https://github.com/webpack/webpack/blob/main/README.md) 创建了一个优秀的打包工具和丰富的生态。
+- [vite-plugin-inspect](https://github.com/antfu/vite-plugin-inspect) 启发了 Rsdoctor 对构建过程分析的探索。

package/docs/zh/blog/topic/_meta.json

@@ -0,0 +1 @@
+["loader-optimization", "duplicate-pkg-problem"]