@modern-js/module-tools-docs 2.0.1 → 2.0.3-beta.0

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

@@ -1,143 +1,140 @@
 ---
 sidebar_position: 3
 ---
-# modify-output-product
 
-## Modify output product
+## Modify the output product
 
 ## Default output products
 
-When the `modern build` command is used in an initialized project, the products are generated according to the default configuration supported by Module Tools. The default supported configurations are as follows.
+When the `modern build` command is used in an initialized project, the products are generated according to the default configuration supported by Module Tools. The default supported configurations are specified as follows.
 
 ```typescript
-import { defineConfig } from '@modern-js/module-tools';
+import moduleTools, { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
-  buildPreset: 'base-config',
+  plugins: [moduleTools()],
+  buildPreset: 'npm-library',
 });
 ```
 
-**The default generated product has the following characteristics**:
-
-- The code format is [CommonJS](https://nodejs.org/api/modules.html#modules-commonjs-modules), or simply `cjs`.
-- Code syntax is supported up to `ES6`.
-- All code is packaged into a single file, i.e. **bundle** processing is performed.
-- The output root directory is the `dist` directory under the project, and the output directory for type files is `dist/types`.
-
-:::tip
+**The default generation product has the following characteristics**.
 
-1. By "code syntax support up to ES6", we mean that the syntax supported by the product code will not exceed `ES6`. If the source code uses syntax above `ES6` (e.g. `ES2017`), it will be converted.
-   :::
+- 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.
+- 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:
+You may have the following questions when you see this.
 
 1. what is `buildPreset`?
-2. what determines these characteristics of the output?
+2. what determines these characteristics of the product?
 
 Then the next step is to first explain `buildPreset`.
 
 ## buildPreset
 
-`buildPreset` represents one or more sets of build-related configurations prepared in advance. By using the corresponding preset values of `buildPreset`, you can eliminate the troublesome and complicated configuration work and get the expected product.
+The `buildPreset` represents one or more sets of build-related configurations prepared in advance. By using the corresponding preset values of the `buildPreset`, you can eliminate the troublesome and complicated configuration work and get the expected product.
 
-### String form of `buildPreset`
+### String form of build preset
 
 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](/en/api/build-config). The relationship between **generic preset strings and variants** is explained here.
+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**.
 
-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 product of the project will have the following characteristics.
 
-- In the `dist/lib` directory you will get the product in the code format `cjs`, with syntax support up to `es6` and after packaging.
-- In the `dist/es` directory, you get code in the format `esm`, with syntax support up to `es6` and packaged.
+- 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/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 modified **code-syntax support** and a string naming change to `"npm-library-[es5 | es2016.... . es2020 | esnext]"`.
+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 `es2017`, then simply changing `"npm-library"` to `"npm-library-es2017"` would be sufficient.
+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.
 
-### Function form of `buildPreset`
+### Build pre-defined function forms
 
 **In addition to the string form, the value of a build preset can also be in the form of a function, where the specific configuration corresponding to a preset value can be printed or modified**.
 
-For example, if the same effect as the preset string `"npm-library-es2017"` is achieved using the preset function form, it can be done as follows:
+For example, to achieve the same effect as the preset string ``npm-library-es5"` using the form of a preset function, you can do the following.
 
 ```typescript
-import { defineConfig } from "@modern-js/module-tools";
+import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
   buildPreset({ preset }) {
     return preset.NPM_LIBRARY.map(config => {
-      return { ... .config, target: 'es2017' }
+      return { ... .config, target: 'es5' }
     });
   },
 });
 ```
 
-In the above code implementation, `preset.NPM_LIBRARY` corresponds to the preset string `"npm-library"`, which represents the `"npm-library"` equivalent of a multi-group build-related configuration. We traverse the `NPM_LIBRARY` array, which contains multiple `buildConfig` objects, with the `map` method. We make a shallow copy of the original `buildConfig` object and modify the shallow copy to get `buildConfig.target`, specifying it as `es2017`.
+In the above code implementation, `preset.NPM_LIBRARY` corresponds to the preset string `"npm-library"`, which represents the `"npm-library"` equivalent of a multi-group build-related configuration. We traverse the `NPM_LIBRARY` array, which contains multiple `buildConfig` objects, with the `map` method. We make a shallow copy of the original `buildConfig` object and modify the shallow copy to get `buildConfig.target`, specifying it as `es5`.
 
-> The specific value of `preset.NPM_LIBRARY` can be viewed via the [BuildPreset API](/en/api/build-config). The `preset` object contains not only `NPM_LIBRARY`, but also other similar constants.
+> NPM_LIBRARY`, you can check it with [BuildPreset API](/api/config/build-preset). The`preset`object contains not only`NPM_LIBRARY`, but also other similar constants.
 
-So what is the `buildConfig` object here? And what are the previously mentioned build product features based on?
+So what is the `buildConfig` object here? What is the basis for the build product feature mentioned before?
 
-We explain it next.
+Let's explain next.
 
 ## Build configuration (object)
 
-**`buildConfig` is a configuration object 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 of the properties that products have, but also some of the features needed to build products. The following is a brief list from a classification point of view:
+**`buildConfig` is a configuration object 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.
 
 **The basic attributes of a build product include:**
 
-- Whether the product is packaged or not: the corresponding API is [`buildConfig.buildType`](/en/api/build-config#buildtype).
-- Product support for syntax: the corresponding API is [`buildConfig.target`](/en/api/build-config#target).
-- Output format: The corresponding API is [`buildConfig.format`](/en/api/build-config#format).
-- How to handle the output type file: the corresponding API is [`buildConfig.dts`](/en/api/build-config#dts).
-- How the sourceMap of the product is handled: the corresponding API is [`buildConfig.sourceMap`](/en/api/build-config#sourcemap).
-- The input (or source file) corresponding to the output: the corresponding API is [`buildConfig.input`](/en/api/build-config#input).
-- The directory of the output of the product: the corresponding API is [`buildConfig.outDir`](/en/api/build-config#outDir).
-- The source directory of the build: the corresponding API is [`buildConfig.sourceDir`](/en/api/build-config#sourcedir).
+- Whether the product is packaged 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).
+- 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).
+- Build source directory: the corresponding API is [`buildConfig.sourceDir`](/api/config/build-config#sourcedir).
 
-**Common functions needed to build products include:**
+**Common functions required for build products include:**
 
-- Alias: The corresponding API is [`buildConfig.alias`](/en/api/build-config#alias).
-- Static resource handling: The corresponding API is [`buildConfig.asset`](/en/api/build-config#asset).
+- 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).
 - Third-party dependency handling: The corresponding APIs are
-  - [`buildConfig.autoExternal`](/en/api/build-config#autoexternal).
-  - [`buildConfig.externals`](/en/api/build-config#externals).
-- Copy: The corresponding API is [`buildConfig.copy`](/en/api/build-config#copy).
-- Global variable substitution: the corresponding API is [`buildConfig.define`](/en/api/build-config#define).
-- Specify [JSX](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) compilation method, the corresponding API is [`buildConfig.jsx`](/en/api/build-config#jsx).
+  - [`buildConfig.autoExternal`](/api/config/build-config#autoexternal).
+  - [`buildConfig.externals`](/api/config/build-config#externals).
+- Copy: The corresponding API is [`buildConfig.copy`](/api/config/build-config#copy).
+- Global variable substitution: the corresponding API is [`buildConfig.define`](/api/config/build-config#define).
+- Specify [JSX](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) compilation method, the corresponding API is [`buildConfig.jsx`](/api/config/ build-config#jsx).
 
 **Some advanced properties or less frequently used functions:**
 
-- Product code compression: The corresponding API is [`buildConfig.minify`](/en/api/build-config#minify).
-- Code splitting: [`buildConfig.splitting`](/en/api/build-config#splitting)
-- Specify whether the build product is for the NodeJS environment or the browser environment: the corresponding API is [`buildConfig.platform`](/en/api/build-config#platform).
+- 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).
 - umd product-related.
-  - Specifies the global variables imported externally to the umd product: the corresponding API is [`buildConfig.umdGlobals`](/en/api/build-config#umdglobals).
-  - Specify the module name of the umd product: the corresponding API is [`buildConfig.umdModuleName`](/en/api/build-config#umdmodulename).
+  - 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).
 
-In addition to the above categories, frequently asked questions and best practices about these APIs can be found at the following links.
+In addition to the above categories, frequently asked questions and best practices about these APIs can be found at the following links
 
-- [What are `bundle` and `bundleless`?](/en/guide/advance/in-depth-about-build#bundle-and-bundleless)
-- [The relationship between `input` and `sourceDir`](/en/guide/advance/in-depth-about-build#relationship-between-input-and-sourcedir)
-- [The multiple ways of generating type files in products](/en/guide/advance/in-depth-about-build#declaration-type-files)
-- [The use of `buildConfig.define` for different scenarios.](/en/guide/advance/in-depth-about-build#buildconfigdefine-usage-for-different-scenarios)
-- [How to handle third-party dependencies?](/en/guide/advance/external-dependency)
-- [How to use copy?](/en/guide/advance/copy)
-- [How to build umd products?](/en/guide/advance/build-umd)
-- [The capabilities currently supported by static resources.](/en/guide/advance/asset)
+- [What are `bundle` and `bundleless`?](/guide/advance/in-depth-about-build#bundle- and-bundleless)
+- [Relationship of `input` to `sourceDir`](/guide/advance/in-depth-about-build#input- to -sourcedir-)
+- [Multiple ways to generate type files in product](/guide/advance/in-depth-about-build#type-files).
+- [`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)
+- [The capabilities currently supported by static resources.](/guide/advance/asset)
 
 ## When to use `buildConfig`
 
-`buildConfig` is one of the ways used to modify the product, **and only `buildConfig` will take effect when configured in conjunction with `buildPreset`**. So if configured as follows.
+`buildConfig` is one of the methods used to modify the product, **only `buildConfig` will take effect when configured in conjunction with `buildPreset`**. So if configured as follows.
 
 ```typescript
 import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
-  buildConfig: [{}],
-  buildPreset: 'base-config',
+  buildConfig: {
+    format: 'umd',
+  },
+  buildPreset: 'npm-library',
 });
 ```
 
@@ -149,4 +146,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 product to get**.

package/docs/en/guide/basic/publish-your-project.md

@@ -20,7 +20,7 @@ An npm-type module project release process consists of two phases.
 
 Once these changes have been made, the current changes need to be documented with the following command.
 
-- [`modern change`](/zh/guide/command-preview#modern-change)
+- [`modern change`](/guide/basic/command-preview#modern-change)
 
 Executing the `modern change` command asks the developer several questions and generates a change log based on the developer's answers. The changelog file contains the type of change and its description, and is committed to the git repository.
 
@@ -53,7 +53,7 @@ publish test
 
 When the project version needs to be updated, execute the following command.
 
-- [`modern bump`](/zh/guide/command-preview#modern-bump)
+- [`modern bump`](/guide/basic/command-preview#modern-bump)
 
 Executing `modern bump` will modify the version number in `package.json` based on the contents of the Markdown file in the `.changeset/` directory where the changes were recorded, and generate the `CHANGELOG.md` file. **These Markdown files are also deleted when the version update is complete, so they are "consumed "**.
 
@@ -71,7 +71,7 @@ Executing `modern bump` will modify the version number in `package.json` based o
 
 To publish a project, you can execute the following command.
 
-- [`modern publish`](/zh/guide/command-preview#modern-release)
+- [`modern publish`](/guide/basic/command-preview#modern-release)
 
 The `modern release` command publishes the project to the npm Registry.
 
@@ -89,7 +89,7 @@ However, if you want to change the version number of the current project to a pr
 
 When a pre-release is needed before the official release, the following command is executed.
 
-- [`modern pre`](/zh/guide/command-preview#modern-pre)
+- [`modern pre`](/guide/basic/command-preview#modern-pre)
 
 First `modern pre enter <tag>` to enter pre-release mode, `<tag>` can be the same as the `tag` specified with the `modern release --tag` command when releasing the project.
 

package/docs/en/guide/basic/test-your-project.mdx

@@ -8,9 +8,7 @@ This chapter will describe how to test modules.
 
 ## Prerequisites and conventions
 
-To use the testing functionality of the project, you need to make sure that the project contains the following dependencies:
-
-- `"@modern-js/plugin-testing"`
+To use the testing features of the project, you need to make sure that the project contains the dependency: `"@modern-js/plugin-testing"` , which can be done with [modern new](/guide/basic/command-preview#modern-new).
 
 In the module engineering scheme, the following conventions are in place for test cases, or files for writing tests:
 
@@ -37,7 +35,7 @@ After execution, you will see the results of the test:
 
 The Module Engineering Program provides the following configurations for testing.
 
-- [`testing`](/zh/api/config-test)
+- [`testing`](/api/config/testing)
 
 You can add it in `modern.config.(j|t)s`.
 
@@ -99,10 +97,12 @@ npm run test
 
 ### Components
 
-For components, Modern.js's [Runtime API](xxx) provides functionality for testing UI components, which is provided by `@modern-js/runtime/testing`.
+{/* 链接待补充 */}
+
+For components, Modern.js's Runtime API provides functionality for testing UI components, which is provided by `@modern-js/runtime/testing`.
 
 :::tip
-If you need to use the Runtime API, then you can turn it on via [microgenerator](/zh/guide/command-preview).
+If you need to use the Runtime API, then you can turn it on via [microgenerator](/guide/basic/command-preview).
 :::
 
 <CH.Spotlight>

package/docs/en/guide/basic/use-micro-generator.md

@@ -12,7 +12,11 @@ The Module Engineering solution provides the Microgenerator tool, which allows f
 
 Thus with these capabilities, **Microgenerator can enable additional feature functionality for the project**.
 
-The microgenerator can be started via [`modern new`](/zh/guide/command-preview). The current Microgenerator features supported by the Module Engineering program are:
+The microgenerator can be started via [`modern new`](/guide/basic/command-preview). The current Microgenerator features supported by the Module Engineering program are:
+
+## Test
+
+When we want to test some modules, we can enable the test test feature. When this feature is enabled, **a `tests` directory and related files will be created in the project directory, and a new `"@modern-js/plugin-testing"` dependency will be added to package.json**.
 
 ## Storybook
 
@@ -20,8 +24,8 @@ The **Storybook feature** can be enabled when we want to debug a component or a
 
 For more information on how to start Storybook and how to use it, check out the following link.
 
-- [`modern dev`](/en/guide/command-preview#modern-dev)
-- [using Storybook](xxx)
+- [`modern dev`](/en/guide/basic/command-preview#modern-dev)
+- [`using Storybook`](/en/guide/basic/using-storybook)
 
 ## Tailwind CSS support
 
@@ -29,10 +33,14 @@ This can be enabled when we want to add [Tailwind CSS](https://v2.tailwindcss.co
 
 For more information on how to use Tailwind CSS in your module projects, check out.
 
-- [Using Tailwind CSS](xxx)
+<!-- 链接待补充 -->
+
+- Using Tailwind CSS
 
 ## Modern.js Runtime API
 
-**Modern.js provides [Runtime API](xxx) capabilities that can only be used in the Modern.js application project environment**. If you need to develop a component for use in a Modern.js application environment, then you can turn on this feature and the microgenerator will add the `"@modern-js/runtime"` dependency.
+<!-- 链接待补充 -->
+
+**Modern.js provides Runtime API capabilities that can only be used in the Modern.js application project environment**. If you need to develop a component for use in a Modern.js application environment, then you can turn on this feature and the microgenerator will add the `"@modern-js/runtime"` dependency.
 
 Also, the Storybook debugging tool will determine if the project needs to use the Runtime API by checking the project's dependencies and providing the same Runtime API runtime environment as the Modern.js application project.

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

@@ -6,8 +6,8 @@ sidebar_position: 5
 
 First of all, if you haven't read the following, take a few minutes to understand it first.
 
-- [use micro-generator to enable Storybook debugging](/en/guide/use-micro-generator#storybook-debug)
-- [`modern dev`](/en/guide/command-preview#modern-dev)
+- [use micro-generator to enable Storybook debugging](/en/guide/basic/use-micro-generator#storybook-debug)
+- [`modern dev`](/en/guide/basic/command-preview#modern-dev)
 
 [Storybook](https://storybook.js.org/) is a tool dedicated to component debugging, providing around component development.
 
@@ -150,8 +150,6 @@ Not only is it impossible to verify that the component product is correct using
 
 ## Configure Storybook
 
-### Configuration file
-
 Storybook is officially configured for projects through a folder called `.storybook`, which contains various configuration files. **In a module project scenario, Storybook configuration files can be added to the `config/storybook` directory of the project.**
 
 For more information on how to use the various Storybook configuration files, see the following links:
@@ -165,15 +163,7 @@ For more information on how to use the various Storybook configuration files, se
 
 In the future we will consider whether these configurations can be allowed to be modified, but for now we are limiting their use to reduce unpredictable issues.
 
-### `dev.storybook`
-
-In addition to the configuration file, the module engineering solution also provides a `dev.storybook` configuration item in the `modern.config.(j|t)s` project configuration file.
-
-The webpack configuration of Storybook can be modified via this configuration.
-
-- [`dev.storybook.webpack`](xxx)
-
-### Building Storybook Products
+## Building Storybook Products
 
 In addition to Storybook debugging of components or common modules, you can also perform Storybook build tasks with the following commands.
 
@@ -183,6 +173,6 @@ modern build --platform storybook
 
 For the `modern build --platform` command you can see.
 
-- [`modern build`](/en/guide/command-preview#modern-build)
+- [`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.