@modern-js/module-tools-docs 2.25.2-beta.0 → 2.26.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # @modern-js/module-tools-docs
 
+## 2.26.0
+
+### Patch Changes
+
+- @modern-js/doc-tools@2.26.0
+- @modern-js/doc-plugin-auto-sidebar@2.26.0
+
+## 2.25.2
+
+### Patch Changes
+
+- 63d8247: docs(module-tools): add faq content and slots components
+  docs(module-tools): 添加 FAQ 内容以及插槽插件
+  - @modern-js/doc-plugin-auto-sidebar@2.25.2
+  - @modern-js/doc-tools@2.25.2
+
 ## 2.25.1
 
 ### Patch Changes

package/docs/en/api/config/build-config.md

@@ -36,7 +36,7 @@ export default {
 };
 ```
 
-After the above configuration is done, if `@common/Foo.tsx` is referenced in the code, it will map to the `<root>/src/common/Foo.tsx` path.
+After the above configuration is done, if `@common/Foo.tsx` is referenced in the code, it will map to the `<project>/src/common/Foo.tsx` path.
 
 When the value of `alias` is defined as a function, you can accept the pre-defined alias object and modify it.
 
@@ -119,7 +119,7 @@ At this point, all static resources will be prefixed with `https://xxx/`
 
 ## asset.svgr
 
-Packaged to handle svg as a React component, options reference [svgr](https://react-svgr.com/docs/options/), plus support for two configuration items `include` and `exclude` to match the svg file to be handled
+Packaged to handle svg as a React component, options reference [svgr](https://react-svgr.com/docs/options/), plus support for two configuration options `include` and `exclude` to match the svg file to be handled
 
 - **Type**: `boolean | object`
 - **Default**: `false`
@@ -184,7 +184,7 @@ export default defineConfig({
 });
 ```
 
-This way the dependencies under `"dependencies"` and `"peerDependencies"` will be packaged. If you want to turn off the processing of only one of these dependencies, you can use the
+This way the dependencies under `"dependencies"` and `"peerDependencies"` will be bundled. If you want to turn off the processing of only one of these dependencies, you can use the
 `buildConfig.autoExternal` in the form of an object.
 
 ```js modern.config.ts
@@ -410,7 +410,7 @@ When using SWC Transform for code transformation, you can enable the `externalHe
 - **Type**: `boolean`
 - **Default**: `false`
 
-Below is a comparison of the product changes before and after using this configuration.
+Below is a comparison of the output file changes before and after using this configuration.
 
 Before enable:
 
@@ -447,7 +447,7 @@ export var yourCode = function () {
 
 ## externals
 
-Configure external dependencies that will not be packaged into the final bundle
+Configure external dependencies that will not be bundled into the final bundle.
 
 - **Type**:
 
@@ -700,7 +700,7 @@ At the same time you set [style.inject](#styleinject) to `true` and you will see
 [LIBUILD:ESBUILD_WARN] Ignoring this import because "other-package/dist/index.css" was marked as having no side effects
 ```
 
-At this point, you can use this configuration item to manually configure the module's `"sideEffects"` to support regular and functional forms.
+At this point, you can use this configuration option to manually configure the module's `"sideEffects"` to support regular and functional forms.
 
 ```js modern.config.ts
 export default defineConfig({
@@ -718,7 +718,7 @@ After adding this configuration, the sideEffects field in package.json will no l
 
 ## sourceDir
 
-Specify the source directory of the build, default is `src`, which is used to generate the corresponding product directory based on the source directory structure when building `bundleless`.
+Specify the source directory of the build, default is `src`, which is used to generate the corresponding output directory based on the source directory structure when building `bundleless`.
 
 - **Type**: `string`
 - **Default**: `src`
@@ -1089,7 +1089,7 @@ Reference the [Import Plugin - Notes](plugins/official-list/plugin-import.html#N
 
 ## umdGlobals
 
-Specify global variables for external import of umd products
+Specify global variables for external import of umd artifacts
 
 - **Type**: `Record<string, string>`
 - **Default**: `{}`
@@ -1123,11 +1123,11 @@ export default {
 };
 ```
 
-At this point the umd product will go to mount on `global.myLib`
+At this point the umd artifact will go to mount on `global.myLib`
 
 :::tip
 
-- The module name of the umd product must not conflict with the global variable name.
+- The module name of the umd artifact must not conflict with the global variable name.
 - Module names will be converted to camelCase, e.g. `my-lib` will be converted to `myLib`, refer to [toIdentifier](https://github.com/babel/babel/blob/main/packages/babel-types/src/converters/toIdentifier.ts).
 
 :::

package/docs/en/api/config/build-preset.mdx

@@ -70,7 +70,7 @@ export const buildConfig = [
 
 ### `'npm-library-with-umd'`
 
-Used under class [NPM](https://www.npmjs.com/) package manager, and Library supports a similar pattern to [unpkg](https://unpkg.com/). Additional `umd` products are provided on top of the pre-defined `npm-library`.
+Used under class [NPM](https://www.npmjs.com/) package manager, and Library supports a similar pattern to [unpkg](https://unpkg.com/). Additional `umd` artifacts are provided on top of the pre-defined `npm-library`.
 
 ```json package.json
 {
@@ -115,9 +115,9 @@ export const buildConfig = [
 
 ### `'npm-component'`
 
-A generic pattern for components (libraries) used under the class [NPM](https://www.npmjs.com/) package manager. Contains both `esm` and `cjs` Bundleless products (for easy _[Tree shaking](https://developer.mozilla.org/zh-CN/docs/Glossary/Tree_shaking)_ optimization), as well as including a copy of the type file.
+A generic pattern for components (libraries) used under the class [NPM](https://www.npmjs.com/) package manager. Contains both `esm` and `cjs` Bundleless artifacts (for easy _[Tree shaking](https://developer.mozilla.org/zh-CN/docs/Glossary/Tree_shaking)_ optimization), as well as including a copy of the type file.
 
-For style files included in the source code, the products provide the compiled product of the style and the source file of the style.
+For style files included in the source code, the artifacts provide the compiled files of the style and the source file of the style.
 
 ```json package.json
 {
@@ -155,7 +155,7 @@ export const buildConfig = [
 
 ### `'npm-component-with-umd'`
 
-Component (library) used under class [NPM](https://www.npmjs.com/) package manager, with support for class [unpkg](https://unpkg.com/) schema. Additional `umd` products are provided on top of the pre-defined `npm-component`.
+Component (library) used under class [NPM](https://www.npmjs.com/) package manager, with support for class [unpkg](https://unpkg.com/) schema. Additional `umd` artifacts are provided on top of the pre-defined `npm-component`.
 
 ```json package.json
 {

package/docs/en/guide/advance/asset.mdx

@@ -35,7 +35,7 @@ Project source code.
 
 ---
 
-If the size of `bg.png` is less than 10 kb, then the product directory structure and product content are.
+If the size of `bg.png` is less than 10 kb, then the output directory structure and file content are.
 
 <CH.Code>
 
@@ -53,7 +53,7 @@ console.info(bg_default);
 
 </CH.Code>
 
-If the size of `bg.png` is larger than 10 kb, then the product directory structure and product content are.
+If the size of `bg.png` is larger than 10 kb, then the output directory structure and file content are.
 
 <CH.Code>
 

package/docs/en/guide/advance/build-umd.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 5
 ---
 
-# Build umd products
+# Build umd artifacts
 
 The full name of umd is **Universal Module Definition**, and JS files in this format can run in multiple runtime environments: the
 
@@ -10,7 +10,7 @@ The full name of umd is **Universal Module Definition**, and JS files in this fo
 - Node.js environment: module loading based on CommonJS
 - Other cases: mount the module on a global object.
 
-We can therefore specify the build product of the project as an umd product in the following way:
+We can therefore specify the build artifacts of the project as an umd artifact in the following way:
 
 ```ts
 export default defineConfig({
@@ -20,10 +20,10 @@ export default defineConfig({
 });
 ```
 
-## Third-party dependency handling for umd products
+## Third-party dependency handling for umd artifacts
 
 In the ["How to handle third-party dependencies"](/en/guide/advance/external-dependency) chapter, we know that we can control whether or not the project packages third-party dependencies via the [`autoExternals`](/en/api/config/build-config#autoexternal) and [`externals`](/en/api/config/build-config#externals) APIs.
-So when building umd products, we can also use it like this:
+So when building umd artifacts, we can also use it like this:
 
 <CH.Spotlight>
 
@@ -74,7 +74,7 @@ console.info(React);
 
 ---
 
-The `react` code is not packaged into the product at this point.
+The `react` code is not bundled into the artifact at this point.
 
 ```js dist/index.js focus=1:7
 (function (global, factory) {
@@ -162,7 +162,7 @@ console.info(React);
 
 ---
 
-At this point we will see the product code like this.
+At this point we will see the output code like this.
 
 ```js dist/index.js focus=12:18
 (function (global, factory) {
@@ -193,7 +193,7 @@ The project can then run in the browser and use the `React` variables that exist
 
 ## Changing the name of a global variable in a project
 
-When we package the following code into an umd product and run it in the browser, we can use the module via `window.index`.
+When we package the following code into an umd artifact and run it in the browser, we can use the module via `window.index`.
 
 ```ts ./src/index.ts
 export default () => {
@@ -201,7 +201,7 @@ export default () => {
 };
 ```
 
-** By default, the name of the source file is used as the name of the module's global variable in the browser. **For the above example, the product would read as follows:
+** By default, the name of the source file is used as the name of the module's global variable in the browser. **For the above example, the artifact would read as follows:
 
 ```js ./dist/index.js focus=9:9
 (function (global, factory) {
@@ -231,7 +231,7 @@ export default defineConfig({
 });
 ```
 
-The construction products at this point are:
+The build artifact at this point are:
 
 ```js ./dist/index.js focus=9:9
 (function (global, factory) {

package/docs/en/guide/advance/copy.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Use the Copy Tools
 
-The Module Project provides the Copy utility for copying already existing individual files or entire directories into the product directory. Next we learn how to use it.
+The Module Project provides the Copy utility for copying already existing individual files or entire directories into the output directory. Next we learn how to use it.
 
 ## Understanding the Copy API
 

package/docs/en/guide/advance/external-dependency.mdx

@@ -19,7 +19,7 @@ In addition to `"dependencies"`, [`"peerDependencies"`](/en/guide/basic/before-g
 
 ## Default handling of third-party dependencies
 
-By default, third-party dependencies under `"dependencies"` and `"peerDependencies"` are not packaged in the module project\*\*.
+By default, third-party dependencies under `"dependencies"` and `"peerDependencies"` are not bundled in the module project\*\*.
 
 This is because when the npm package is installed, its `"dependencies"` will also be installed. By not packaging `"dependencies"`, you can reduce the size of the package product.
 
@@ -66,7 +66,7 @@ console.info(React);
 
 ---
 
-The `react` code is not packaged into the product at this point.
+The `react` code is not bundled into the artifact at this point.
 
 ```js dist/index.js
 import React from 'react';

package/docs/en/guide/advance/in-depth-about-build.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # In-depth understanding of build
 
-In the "Basic Usage" section, we already knew that you can modify the output product of a project through the `buildConfig` configuration. `buildConfig` not only describes some of the features of the product, but also provides some functionality for building the product.
+In the "Basic Usage" section, we already knew that you can modify the output files of a project through the `buildConfig` configuration. `buildConfig` not only describes some of the features of the product, but also provides some functionality for building the product.
 
 :::tip
 If you are not familiar with `buildConfig`, please read [modify-output-product](/en/guide/basic/modify-output-product).
@@ -20,11 +20,11 @@ So first let's understand Bundle and Bundleless.
 
 A Bundle is a package of build products, which may be a single file or multiple files based on a certain [code splitting strategy](https://esbuild.github.io/api/#splitting).
 
-Bundleless, on the other hand, means that each source file is compiled and built separately, but not packaged together. Each product file can be found with its corresponding source code file. The process of **Bundleless build can also be understood as the process of code conversion of source files only**.
+Bundleless, on the other hand, means that each source file is compiled and built separately, but not bundled together. Each output file can be found with its corresponding source code file. The process of **Bundleless build can also be understood as the process of code conversion of source files only**.
 
 They have their own benefits.
 
-- Bundle can reduce the size of build products and also pre-package dependencies to reduce the size of installed dependencies. Packaging libraries in advance can speed up application project builds.
+- Bundle can reduce the size of build artifacts and also pre-package dependencies to reduce the size of installed dependencies. Packaging libraries in advance can speed up application project builds.
 - Bundleless maintains the original file structure and is more conducive to debugging and tree shaking.
 
 :::warning
@@ -48,7 +48,7 @@ We know from the defaults: **Bundle builds can generally specify a file path as
 
 #### Object type of `input`
 
-In addition to setting `input` to an array, you can also set it to an object during the Bundle build process. **By using the object form, we can modify the name of the file that the build product outputs**. So for the following example, `. /src/index.ts` corresponds to the path of the build product file as `. /dist/main.js`.
+In addition to setting `input` to an array, you can also set it to an object during the Bundle build process. **By using the object form, we can modify the name of the file that the build artifacts outputs**. So for the following example, `. /src/index.ts` corresponds to the path of the build artifacts file as `. /dist/main.js`.
 
 ```js modern.config.ts
 import { defineConfig } from '@modern-js/module-tools';
@@ -103,9 +103,9 @@ The build speed is generally improved by closing the type file.
 
 With `buildType: 'bundleless'`, type files are generated using the project's `tsc` command to complete production.
 
-The **module engineering solution also supports packaging of type files**, although care needs to be taken when using this feature.
+The **Module Tools also supports bundling of type files**, although care needs to be taken when using this feature.
 
-- Some third-party dependencies have incorrect syntax that can cause the packaging process to fail. So in this case, you need to exclude such third-party packages manually with [`buildConfig.externals`](/en/api/config/build-config#externals).
+- Some third-party dependencies have incorrect syntax that can cause the bundling process to fail. So in this case, you need to exclude such third-party packages manually with [`buildConfig.externals`](/en/api/config/build-config#externals).
 - It is not possible to handle the case where the type file of a third-party dependency points to a `.ts` file. For example, the `package.json` of a third-party dependency contains something like this: `{"types": ". /src/index.ts"}`.
 
 #### Alias Conversion
@@ -116,7 +116,7 @@ During the Bundleless build process, if an alias appears in the source code, e.g
 import utils from '@common/utils';
 ```
 
-Normally, product type files generated with `tsc` will also contain these aliases. However, Module Tools will convert the aliases in the type file generated by `tsc` to:
+Normally, the type files generated with `tsc` will also contain these aliases. However, Module Tools will convert the aliases in the type file generated by `tsc` to:
 
 - Alias conversion is possible for code of the form `import '@common/utils'` or `import utils from '@common/utils'`.
 - Aliasing is possible for code of the form `export { utils } from '@common/utils'`.
@@ -133,7 +133,7 @@ General usage:
 import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
-  // The output path of the packaged type file at this point is `./dist/types`
+  // The output path of the bundled type file at this point is `./dist/types`
   buildConfig: {
     buildType: 'bundle',
     dts: {
@@ -151,7 +151,7 @@ For the use of `dts.only`:
 import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
-  // At this moment the type file is not packaged and the output path is `./dist/types`
+  // At this moment the type file is not bundled and the output path is `./dist/types`
   buildConfig: [
     {
       buildType: 'bundle',
@@ -239,8 +239,8 @@ declare const YOUR_ADD_GLOBAL_VAR;
 
 When the `modern build` command is executed, the
 
-- Clear the products directory according to `buildConfig.outDir`.
-- Compile `js/ts` source code to generate the JS build product for Bundle/Bundleless.
+- Clear the output directory according to `buildConfig.outDir`.
+- Compile `js/ts` source code to generate the JS build artifacts for Bundle/Bundleless.
 - Generate Bundle/Bundleless type files using `tsc`.
 - Handle Copy tasks.
 

package/docs/en/guide/advance/in-depth-about-dev-command.md

@@ -18,7 +18,7 @@ In addition to the `dev` command, you can also start a debugging tool or task di
 
 ## Extending the dev command
 
-If you need to extend the dev command, or rather provide your own Module Tools debugging tool plug-in, then you will need to know the following first.
+If you need to extend the dev command, or rather provide your own Module Tools debugging tool plugin, then you will need to know the following first.
 
 * [Development of plugins](plugins/guide/getting-started)
 * [Debugging Tools Plugin API](/api/plugin-api/plugin-hooks#调试钩子)

package/docs/en/guide/basic/before-getting-started.md

@@ -6,7 +6,7 @@ sidebar_position: 1
 
 ## Environment preparation
 
-In order to use the Modern.js module engineering solution, you first need [NodeJS](https://nodejs.org/zh/) engine, we recommend the latest [LTS version](https://github.com/nodejs/Release), and make sure the Node version is **>=14.18.0**. because non-stable NodeJS releases frequently have bugs. You might consider installing via [nvm-windows](https://github.com/coreybutler/nvm-windows) and [nvm](https://github.com/nvm-sh/nvm) (Mac / Linux), so you can easily switch to different NodeJS versions that might be required for different projects that you work on.
+In order to use the Modern.js Module Tools, you first need [NodeJS](https://nodejs.org/zh/) engine, we recommend the latest [LTS version](https://github.com/nodejs/Release), and make sure the Node version is **>=14.18.0**. because non-stable NodeJS releases frequently have bugs. You might consider installing via [nvm-windows](https://github.com/coreybutler/nvm-windows) and [nvm](https://github.com/nvm-sh/nvm) (Mac / Linux), so you can easily switch to different NodeJS versions that might be required for different projects that you work on.
 
 ## Getting Started with npm
 

package/docs/en/guide/basic/command-preview.md

@@ -19,7 +19,7 @@ Options:
                          ". /tsconfig.json")
   --platform [platform] Build products for all or specified platforms
   --no-dts disables DTS type file generation and type checking
-  --no-clear disables automatic clearing of product output directories
+  --no-clear disables automatic clearing of output directories
   -h, --help Show information about the current command
 ```
 
@@ -28,12 +28,12 @@ When you want to start a project build, you can execute the `modern build` comma
 - When wanting to start a build in watch mode, use the `--watch` option.
 - When you want to specify the path to the TypeScript configuration file read by the project build, use `-build --tsconfig . /path/config.json` option. This option overrides all [`buildConfig`](/api/config/build-config) configurations in [`dts.tsconfigPath`](/api/config/build-config).
 - The `-no-dts` option can be used when the DTS type file generation and type checking behavior of the project needs to be turned off. **Note: The generation of type files depends on the results of type checking. If type checking is turned off, then type files will not be generated either**.
-- The `--no-clear` option can be used when the automatic clearing of the product output directory needs to be turned off.
+- The `--no-clear` option can be used when the automatic clearing of the output directory needs to be turned off.
 
-In addition to the above, module projects also support `platform` build mode, which can be used to perform build tasks for other tools. For example, it is currently officially supported to start a Storybook build task to generate Storybook products by executing the `modern build --platform` or `modern build --platform storybook` commands after installing the `@modern-js/plugin-storybook` plugin.
+In addition to the above, module projects also support `platform` build mode, which can be used to perform build tasks for other tools. For example, it is currently officially supported to start a Storybook build task to generate Storybook artifacts by executing the `modern build --platform` or `modern build --platform storybook` commands after installing the `@modern-js/plugin-storybook` plugin.
 
 :::tip
-When executing a Storybook build, if you need to read the build product of the project. Then **don't forget to execute the `modern build` command to ensure the existence of the project's build product before executing the `modern build --platform` command to start the Storybook build**.
+When executing a Storybook build, if you need to read the build artifacts of the project. Then **don't forget to execute the `modern build` command to ensure the existence of the project's build artifacts before executing the `modern build --platform` command to start the Storybook build**.
 :::
 
 ## `modern new`
@@ -76,7 +76,7 @@ Commands:
 [dev-tools-subCommand]
 ```
 
-The module engineering solution provides the ability to use debugging tools, which can be started with the `modern dev` command. Note, however, that no debugging-related plugins are provided by default, so executing `modern dev` will prompt: _"No dev tools found available "_.
+The Module Tools provides the ability to use debugging tools, which can be started with the `modern dev` command. Note, however, that no debugging-related plugins are provided by default, so executing `modern dev` will prompt: _"No dev tools found available "_.
 
 The officially supported debugging tool is [Storybook](https://storybook.js.org/), so you can run `modern dev` or `modern dev storybook` to execute it after you run `modern new` to enable it.
 

package/docs/en/guide/basic/modify-output-product.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 
 ## Default output products
 
-When you use the `modern build` command in an initialized project, Module Tools will generate corresponding build products based on the current configuration.
+When you use the `modern build` command in an initialized project, Module Tools will generate corresponding build artifacts based on the current configuration.
 
 The default configuration is as follows:
 
@@ -21,11 +21,11 @@ export default defineConfig({
 });
 ```
 
-**The default generation product has the following characteristics**.
+**The default output files has the following characteristics**.
 
 - will generate [CommonJS](https://nodejs.org/api/modules.html#modules-commonjs-modules) and [ESM](https://nodejs.org/api/esm.html#modules- ecmascript-modules).
 - The code syntax is supported up to `ES6` , and more advanced syntax will be converted.
-- All code is packaged into one file, i.e. **bundle** processing is performed.
+- All code is bundled into one file, i.e. **bundle** processing is performed.
 - The output root directory is the `dist` directory under the project, and the type file output directory is `dist/types`.
 
 You may have the following questions when you see this.
@@ -43,17 +43,17 @@ The `buildPreset` represents one or more sets of build-related configurations pr
 
 The value of a **build preset can be in the form of a string**, so a build preset of this form is called a preset string.
 
-The module engineering solution provides generic build preset strings and corresponding variants, depending on the generic scenario in which the npm package is used. All currently supported preset strings can be viewed via the [BuildPreset API](/api/config/build-preset). Here is an explanation about the relationship between **generic preset strings and variants**.
+The Module Tools provides generic build preset strings and corresponding variants, depending on the generic scenario in which the npm package is used. All currently supported preset strings can be viewed via the [BuildPreset API](/api/config/build-preset). Here is an explanation about the relationship between **generic preset strings and variants**.
 
-Among the generic preset strings, `"npm-library"` can be used in the scenario of developing npm packages of the library type, which is suitable for most common module type projects. When `"npm-library"` is set, the output product of the project will have the following characteristics.
+Among the generic preset strings, `"npm-library"` can be used in the scenario of developing npm packages of the library type, which is suitable for most common module type projects. When `"npm-library"` is set, the output files of the project will have the following characteristics.
 
-- In the `dist/lib` directory you will get code formatted as `cjs`, syntax supported up to `es6` and packaged.
-- In the `dist/es` directory, you get code in the format `esm`, with syntax support up to `es6` and after packaging.
+- In the `dist/lib` directory you will get code formatted as `cjs`, syntax supported up to `es6` and bundled.
+- In the `dist/es` directory, you get code in the format `esm`, with syntax support up to `es6` and after bundling.
 - In the `dist/types` directory, you get the type files. If it is not a TypeScript project, there is no such directory.
 
 The default string `"npm-library"` is a variant of the original product with a modified **code syntax support** feature and a string naming change to `"npm-library-[es5 | es2016.... . es2020 | esnext]"`.
 
-For example, if the output product is based on the preset string `"npm-library"` and the syntax supported by the product code is changed to `es5`, then simply changing `"npm-library"` to `"npm-library-es5"` would be sufficient.
+For example, if the output file is based on the preset string `"npm-library"` and the syntax supported by the output code is changed to `es5`, then simply changing `"npm-library"` to `"npm-library-es5"` would be sufficient.
 
 ### Build pre-defined function forms
 
@@ -88,26 +88,26 @@ In addition, under the `preset` object, it not only includes `NPM_LIBRARY`, but
 We can not only use `preset.NPM_LIBRARY`to get the build configuration corresponding to`"npm-library"`, but also `preset['npm-library']` in this way.
 :::
 
-So what is the `buildConfig` object here? What is the basis for the build product feature mentioned before?
+So what is the `buildConfig` object here? What is the basis for the build artifacts feature mentioned before?
 
 Let's explain next.
 
 ## Build configuration (object)
 
-**`buildConfig` is a configuration option that describes how to compile and generate build products**. What was mentioned at the beginning about "_features of build products_" are actually properties supported by `buildConfig`. The currently supported properties cover the needs of most module type projects when building products. `buildConfig` not only contains some properties that products have, but also contains some features needed to build products. The following is a brief list from a classification point of view.
+**`buildConfig` is a configuration option that describes how to compile and generate build artifacts**. What was mentioned at the beginning about "_features of build products_" are actually properties supported by `buildConfig`. The currently supported properties cover the needs of most module type projects when building products. `buildConfig` not only contains some properties that artifacts have, but also contains some features needed to build products. The following is a brief list from a classification point of view.
 
-**The basic attributes of a build product include:**
+**The basic attributes of a build artifacts include:**
 
-- Whether the product is packaged or not: the corresponding API is [`buildConfig.buildType`](/api/config/build-config#buildtype).
+- Whether the artifact is bundled or not: the corresponding API is [`buildConfig.buildType`](/api/config/build-config#buildtype).
 - Product support for syntax: the corresponding API is [`buildConfig.target`](/api/config/build-config#target).
 - Output format: the corresponding API is [`buildConfig.format`](/api/config/build-config#format).
 - How the output type file is handled: the corresponding API is [`buildConfig.dts`](/api/config/build-config#dts).
-- How the sourceMap of the product is handled: the corresponding API is [`buildConfig.sourceMap`](/api/config/build-config#sourcemap).
+- How the sourceMap of the artifact is handled: the corresponding API is [`buildConfig.sourceMap`](/api/config/build-config#sourcemap).
 - The input (or source file) corresponding to the output: the corresponding API is [`buildConfig.input`](/api/config/build-config#input).
-- The directory of the output of the product: the corresponding API is [`buildConfig.outDir`](/api/config/build-config#outDir).
+- The directory of the output of the artifact: the corresponding API is [`buildConfig.outDir`](/api/config/build-config#outDir).
 - Build source directory: the corresponding API is [`buildConfig.sourceDir`](/api/config/build-config#sourcedir).
 
-**Common functions required for build products include:**
+**Common functions required for build artifacts include:**
 
 - Alias: The corresponding API is [`buildConfig.alias`](/api/config/build-config#alias).
 - Static resource handling: the corresponding API is [`buildConfig.asset`](/api/config/build-config#asset).
@@ -122,7 +122,7 @@ Let's explain next.
 
 - Product code compression: The corresponding API is [`buildConfig.minify`](/api/config/build-config#minify).
 - Code splitting: [`buildConfig.splitting`](/api/config/build-config#splitting)
-- Specify whether the build product is for the NodeJS environment or the browser environment: the corresponding API is [`buildConfig.platform`](/api/config/build-config#platform).
+- Specify whether the build artifacts is for the NodeJS environment or the browser environment: the corresponding API is [`buildConfig.platform`](/api/config/build-config#platform).
 - umd product-related.
   - Specifies the global variables imported externally to the umd product: the corresponding API is [`buildConfig.umdGlobals`](/api/config/build-config#umdglobals).
   - Specify the module name of the umd product: the corresponding API is [`buildConfig.umdModuleName`](/api/config/build-config#umdmodulename).
@@ -135,7 +135,7 @@ In addition to the above categories, frequently asked questions and best practic
 - [`buildConfig.define` Different ways to use it for different scenarios.](/guide/advance/in-depth-about-build#buildconfigdefine - How to use it for different scenarios)
 - [How to handle third-party dependencies?](/guide/advance/external-dependency)
 - [How to use copy?](/guide/advance/copy)
-- How do I build umd products? (/guide/advance/build-umd# sets the global variable name of the project)
+- How do I build umd artifacts? (/guide/advance/build-umd# sets the global variable name of the project)
 - [The capabilities currently supported by static resources.](/guide/advance/asset)
 
 ## When to use `buildConfig`
@@ -161,4 +161,4 @@ Since both 'buildConfig' and 'buildPreset' are present, only the 'buildConfig' c
 
 The set or sets of build-related configurations represented by `buildPreset` are composed of `buildConfig`, **which can be used to customize output products** when the current project needs cannot be met using `buildPreset`.
 
-The process of using `buildConfig` is the process of thinking about **what kind of build product to get**.
+The process of using `buildConfig` is the process of thinking about **what kind of build artifacts to get**.

package/docs/en/guide/basic/using-storybook.mdx

@@ -197,4 +197,4 @@ For the `modern build --platform` command you can see.
 
 - [`modern build`](/en/guide/basic/command-preview#modern-build)
 
-After the build is complete, you can see the build product files in the `dist/storybook-static` directory.
+After the build is complete, you can see the build artifacts files in the `dist/storybook-static` directory.

package/docs/en/guide/best-practices/components.mdx

@@ -1,6 +1,6 @@
 # Developing Components
 
-This chapter will describe how to develop component projects using the module engineering solution.
+This chapter will describe how to develop component projects using the Module Tools.
 
 ## Initialize the project
 
@@ -176,7 +176,7 @@ While importing source code for debugging is also supported, debugging using pro
 
 Debugging with source code has a limitation: some configurations are not equivalent in Storybook and in the original build support.
 
-**This is why debugging with the product is recommended**.
+**This is why debugging with the output code is recommended**.
 
 ```tsx ./stories/index.stories.tsx
 import Component from '../src';
@@ -615,11 +615,11 @@ export default () => {
 };
 ```
 
-In Bundle mode, third-party dependencies are packaged in.
+In Bundle mode, third-party dependencies are bundled in.
 
-For styles, a separate product file is generated, and there is no code related to importing styles in the JS output files.
+For styles, a separate output file is generated, and there is no code related to importing styles in the JS output files.
 
-If you need to inject styles into JS products, you can enable the [`style.inject`](/en/api/config/build-config#styleinject) option.
+If you need to inject styles into JS output files, you can enable the [`style.inject`](/en/api/config/build-config#styleinject) option.
 
 <CH.Code>
 ```css ./dist/es/index.css
@@ -703,7 +703,7 @@ export {
 ```
 </CH.Code>
 
-In Bundleless mode, no third-party dependencies are packaged in, and no style products are generated at this time.
+In Bundleless mode, no third-party dependencies are bundled, and no style artifacts are generated at this time.
 
 ```js ./dist/es/index.js
 import { jsx } from 'react/jsx-runtime';
@@ -753,7 +753,7 @@ export default () => {
 
 ## Configuring build products
 
-Based on most scenarios of component project usage, **it is recommended to use the `npm-component` build preset**. This preset yields a product directory structure of
+Based on most scenarios of component project usage, **it is recommended to use the `npm-component` build preset**. This preset yields a output directory structure of
 
 ```bash
 .
@@ -763,8 +763,8 @@ Based on most scenarios of component project usage, **it is recommended to use t
 │   └── types
 ```
 
-- `. /dist/es`: Contains bundleless products in ES modules format that support the es6 syntax.
-- `. /dist/lib`: Contains bundleless products in CommonJS format with support for es6 syntax.
+- `. /dist/es`: Contains bundleless artifacts in ES modules format that support the es6 syntax.
+- `. /dist/lib`: Contains bundleless artifacts in CommonJS format with support for es6 syntax.
 - `. /dist/types`: Contains the types file.
 
 The [`buildPreset`](/en/api/config/build-preset) can be configured manually if there is a requirement to use syntax support, and supports modifying the supported syntax by adding a suffix to `npm-component`.
@@ -775,7 +775,7 @@ export default defineConfig({
 });
 ```
 
-If you have special needs for the build product directory structure, you can use the [`buildConfig` API](/en/api/config/build-config), which can be used by the following documentation.
+If you have special needs for the build artifacts directory structure, you can use the [`buildConfig` API](/en/api/config/build-config), which can be used by the following documentation.
 
 - [modify-output-product](/en/guide/basic/modify-output-product#build-configuration-object)
 - [in-depth-about-build](/en/guide/advance/in-depth-about-build)

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

@@ -118,7 +118,7 @@ If you import a cjs product from a third-party npm package, the resulting produc
 
 #### Solution
 
-1. **First you need to find which third-party package is causing the problem**. For example, if the error message points to the `react` package, then look for a third-party package that has code like `require('react')` in it. For example [`react-draggable`](https://web-bnpm.byted.org/package/react-draggable), which only contains `cjs` products, then the problem is localized to the `react-draggable` package.
+1. **First you need to find which third-party package is causing the problem**. For example, if the error message points to the `react` package, then look for a third-party package that has code like `require('react')` in it. For example [`react-draggable`](https://www.npmjs.com/package/react-draggable), which only contains `cjs` products, then the problem is localized to the `react-draggable` package.
 2. Then we need to exclude this package with the following configuration, i.e. **not package problematic third-party packages**.
 
 ``` ts

package/docs/en/guide/intro/welcome.md

@@ -6,7 +6,7 @@ sidebar_position: 1
 
 Module Tools is a modules engineering solution for Modern.js, as well as a core dependency. It allows developers to build, debug, and publish module type project more easily. A module type project can mostly be thought of as an npm package type project, which may be a component, component library or tool library project.
 
-If you are planning to develop a project of the npm package type, then you came to the right place! Modern.js provides a professional module engineering solution. It gives you:
+If you are planning to develop a project of the npm package type, then you came to the right place! Modern.js provides a professional Module Tools. It gives you:
 
 - **Simple project initialization**: simply execute the `npx @modern-js/create project-dir` command, followed by a few interactive questions, to create a complete module type project. The created project also supports the choice of two package managers, [**pnpm**](https://pnpm.io/) and [**Yarn**](https://classic.yarnpkg.com/).
 - **Code formatting**: In a module project, you can execute `modern lint` to format the code. The initialized module project includes the [ESLint](https://eslint.org/docs/latest/user-guide/core-concepts#what-is-eslint) ruleset for Modern.js for most scenarios.
@@ -14,5 +14,5 @@ If you are planning to develop a project of the npm package type, then you came
 - **Storybook debugging tools**: Module Tools provides [Storybook](https://storybook.js.org/) debugging tools for debugging module projects. After installing the Storybook plugin for Module Tools, you can start it with the `modern dev storybook` command. You can use Storybook not only for debugging components, but also for other types of modules.
 - **Testing capabilities with Jest**: When you need to test a module, you can use the `modern test` command of Module Tools, which not only integrates with [Jest](https://jestjs.io/), but also provides an API for configuring [Jest](https://jestjs.io/docs/configuration).
 - **Versioning based on Changesets**: When you need to record changes to a project, you can use the `modern change` command to generate a Markdown file containing the changes; when you need to upgrade a project, you can use the `modern bump` command to analyze and upgrade the version through the Markdown file; when you need to release a project, you can use the `modern release` command to release the project; Module Tools implements these commands based on [Changesets](https://github.com/changesets/changesets).
-- **Extensible plug-in mechanism**: Want to integrate additional debugging tools for your project? Or maybe you want to do some extra processing during the build process, Module Tools provides a plugin mechanism and plugin hooks that cover both the `dev` command and the `build` command process. You can use them to extend the capabilities of your project.
+- **Extensible plugin mechanism**: Want to integrate additional debugging tools for your project? Or maybe you want to do some extra processing during the build process, Module Tools provides a plugin mechanism and plugin hooks that cover both the `dev` command and the `build` command process. You can use them to extend the capabilities of your project.
 - **Lots more!** Module Tools will continue to optimize its build and debug features in the future. If there are important issues to be solved in module project building, or if a mainstream module project debugging tool or pattern emerges, then they will probably be supported by Module Tools.

package/docs/en/plugins/guide/getting-started.mdx

@@ -80,5 +80,5 @@ With the above example, we learned the following things.
 
 In addition to the above, we also need to understand.
 
-- [plugin objects, type definitions and recommended configuration items](/en/plugins/guide/plugin-object)
+- [plugin objects, type definitions and recommended configuration options](/en/plugins/guide/plugin-object)
 - [setup functions, `api` object parameters, lifecycle hooks](/en/plugins/guide/setup-function)