@modern-js/module-tools-docs 2.0.0-beta.4 → 2.0.1

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

@@ -1,10 +1,15 @@
+---
+sidebar_position: 3
+---
+# modify-output-product
+
 ## Modify 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.
 
-``` typescript
+```typescript
 import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
@@ -20,8 +25,9 @@ export default defineConfig({
 - The output root directory is the `dist` directory under the project, and the output directory for type files is `dist/types`.
 
 :::tip
+
 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.
-:::
+   :::
 
 You may have the following questions when you see this:
 
@@ -56,7 +62,7 @@ For example, if the output product is based on the preset string `"npm-library"`
 
 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:
 
-``` typescript
+```typescript
 import { defineConfig } from "@modern-js/module-tools";
 
 export default defineConfig({
@@ -69,6 +75,7 @@ export default defineConfig({
 ```
 
 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`.
+
 > 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.
 
 So what is the `buildConfig` object here? And what are the previously mentioned build product features based on?
@@ -77,7 +84,7 @@ We explain it 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 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:
 
 **The basic attributes of a build product include:**
 
@@ -87,7 +94,7 @@ We explain it next.
 - 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 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).
 
 **Common functions needed to build products include:**
@@ -95,8 +102,8 @@ We explain it next.
 - 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).
 - Third-party dependency handling: The corresponding APIs are
-  * [`buildConfig.autoExternal`](/en/api/build-config#autoexternal).
-  * [`buildConfig.externals`](/en/api/build-config#externals).
+  - [`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).
@@ -107,25 +114,25 @@ We explain it next.
 - 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).
 - 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`](/en/api/build-config#umdglobals).
+  - Specify the module name of the umd product: the corresponding API is [`buildConfig.umdModuleName`](/en/api/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.
 
-* [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`?](/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)
 
 ## 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.
 
-``` typescript
+```typescript
 import { defineConfig } from '@modern-js/module-tools';
 
 export default defineConfig({
@@ -136,10 +143,10 @@ export default defineConfig({
 
 Then at this point you will see the following prompt.
 
-``` bash
+```bash
 Since both 'buildConfig' and 'buildPreset' are present, only the 'buildConfig' configuration will take effect
 ```
 
 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

@@ -1,26 +1,30 @@
+---
+sidebar_position: 7
+---
+
 # Versioning and Publishing
 
 An npm-type module project release process consists of two phases.
 
-* The first phase is during development, where the developer needs to provide a change file to record changes that need to be released.
-* The second phase is during release, where Module Tools can collect all the change files to update the version, update the release log, and release new packages to the [npm Registry](https://www.npmjs.com/).
+- The first phase is during development, where the developer needs to provide a change file to record changes that need to be released.
+- The second phase is during release, where Module Tools can collect all the change files to update the version, update the release log, and release new packages to the [npm Registry](https://www.npmjs.com/).
 
 ## Tracking changes
 
 **Changes need to be logged when they happen to the project**. Changes that occur in a project are typically.
 
-* New features
-* Fixes to issues
-* Configuration file changes
-* ...
+- New features
+- Fixes to issues
+- Configuration file changes
+- ...
 
 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`](/zh/guide/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.
 
-``` bash
+```bash
 $ npx modern change
 🦋 What kind of change is this for module-example? (current version is 0.1.0) - patch
 🦋 Please enter a summary for this change (this will be in the changelogs). Submit empty line to open external editor
@@ -37,7 +41,7 @@ $ npx modern change
 
 When executed successfully, the resulting Markdown file containing the change log is saved in the project's `.changeset` directory. The contents will look like the following.
 
-``` markdown .changeset/brave-dryers-agree.md
+```markdown .changeset/brave-dryers-agree.md
 ---
 "``module-example'': patch
 ---
@@ -49,14 +53,15 @@ publish test
 
 When the project version needs to be updated, execute the following command.
 
-* [`modern bump`](/zh/guide/command-preview#modern-bump)
+- [`modern bump`](/zh/guide/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 "**.
 
-``` markdown CHANGELOG.md
+```markdown CHANGELOG.md
 # module
 
 ## 0.1.1
+
 ### Patch Changes
 
 - publish test
@@ -66,13 +71,13 @@ 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`](/zh/guide/command-preview#modern-release)
 
 The `modern release` command publishes the project to the npm Registry.
 
 The release is the `latest` version, which is also the official version. If you want to change the `dist-tag`, you can specify it with the `modern release --tag` command. For example.
 
-``` bash
+```bash
 modern release --tag beta
 ```
 
@@ -84,11 +89,11 @@ 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`](/zh/guide/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.
 
-``` bash
+````bash
 $ npx modern pre enter next
 🦋 success Entered pre mode with tag next
 🦋 info Run `changeset version` to version packages with prerelease versions
@@ -105,11 +110,8 @@ $ npx modern bump
 🦋 warn You can then run `changeset version` again to do a normal release
 🦋 warn ----------------------------------------------------------------------
 🦋 All files have been updated. review them and commit at your leisure
-```
+````
 
 Then you can see that the updated version number in `package.json` will look like this: `0.1.2-next.0`.
 
 Finally, **if you don't need to do a pre-release anymore, be sure to run the `modern pre exit` command** to exit the pre-release state and to release the official version when you run the `modern bump` command again.
-
-
-Translated with www.DeepL.com/Translator (free version)

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

@@ -1,3 +1,7 @@
+---
+sidebar_position: 6
+---
+
 # Testing Projects
 
 This chapter will describe how to test modules.
@@ -6,20 +10,19 @@ This chapter will describe how to test modules.
 
 To use the testing functionality of the project, you need to make sure that the project contains the following dependencies:
 
-* `"@modern-js/plugin-testing"`
+- `"@modern-js/plugin-testing"`
 
 In the module engineering scheme, the following conventions are in place for test cases, or files for writing tests:
 
-* The `tests` directory in the project directory is the directory for test cases and test files, **no support for changing the directory for running test cases**.
-* Files with the suffix `.test.[tj]sx?` are automatically recognized as test files by default.
-* Other `. [tj]sx?` suffixes are recognized as normal files that can be used as test `utils` files or for other purposes.
-
+- The `tests` directory in the project directory is the directory for test cases and test files, **no support for changing the directory for running test cases**.
+- Files with the suffix `.test.[tj]sx?` are automatically recognized as test files by default.
+- Other `. [tj]sx?` suffixes are recognized as normal files that can be used as test `utils` files or for other purposes.
 
 ## Run the tests
 
 Once the dependencies are prepared and we know where to write the test cases, we can execute the tests with the following command:
 
-``` bash
+```bash
 modern test
 
 // Update snapshot
@@ -28,13 +31,13 @@ modern test --updateSnapshot
 
 After execution, you will see the results of the test:
 
-![test-result](/test-result.png)
+![test-result](https://lf3-static.bytednsdoc.com/obj/eden-cn/uhbfnupenuhf/test-result.png)
 
 ## Usage Configuration
 
 The Module Engineering Program provides the following configurations for testing.
 
-* [`testing`](/zh/api/config-test)
+- [`testing`](/zh/api/config-test)
 
 You can add it in `modern.config.(j|t)s`.
 
@@ -46,7 +49,7 @@ For common modules, we can use the test function as follows:
 
 <CH.Spotlight>
 
-``` typescript ./src/index.ts
+```typescript ./src/index.ts
 export default function () {
   return 'hello world';
 }
@@ -56,7 +59,7 @@ export default function () {
 
 First is the code of the module.
 
-``` typescript ./src/index.ts
+```typescript ./src/index.ts
 export default function () {
   return 'hello world';
 }
@@ -68,7 +71,7 @@ Then in the test file, we can do this.
 
 Where `@` points to the source directory, defined in `tests/tsconfig.json` in the initialization project.
 
-``` typescript ./tests/index.test.ts
+```typescript ./tests/index.test.ts
 import main from '@/index';
 
 describe('default cases', () => {
@@ -84,7 +87,7 @@ describe('default cases', () => {
 
 Finally we can execute `modern test`.
 
-``` bash
+```bash
 pnpm test
 ## or
 yarn test
@@ -104,7 +107,7 @@ If you need to use the Runtime API, then you can turn it on via [microgenerator]
 
 <CH.Spotlight>
 
-``` tsx ./src/index.tsx
+```tsx ./src/index.tsx
 export const default () {
   return (
     <div>This is a UI Component</div>
@@ -116,7 +119,7 @@ export const default () {
 
 First is the code of the component.
 
-``` tsx ./src/index.tsx
+```tsx ./src/index.tsx
 export const default () {
   return (
     <div>This is a UI Component</div>
@@ -130,7 +133,7 @@ Then in the test file, we can do this.
 
 Where `@` points to the source directory, defined in `tests/tsconfig.json` in the initialization project.
 
-``` tsx ./tests/index.test.tsx
+```tsx ./tests/index.test.tsx
 import { render, screen } from '@modern-js/runtime/testing';
 
 import Component from '@/index';
@@ -147,7 +150,7 @@ describe('default cases', () => {
 
 Finally we can execute `modern test`.
 
-``` bash
+```bash
 pnpm test
 ## or
 yarn test

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

@@ -1,10 +1,14 @@
+---
+sidebar_position: 4
+---
+
 # Using the Microgenerator
 
 The Module Engineering solution provides the Microgenerator tool, which allows for the current project to.
 
-* add new directories and files
-* Modify the contents of the `package.json` file
-* Execute commands
+- add new directories and files
+- Modify the contents of the `package.json` file
+- Execute commands
 
 Thus with these capabilities, **Microgenerator can enable additional feature functionality for the project**.
 
@@ -16,8 +20,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/command-preview#modern-dev)
+- [using Storybook](xxx)
 
 ## Tailwind CSS support
 
@@ -25,8 +29,7 @@ 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](xxx)
 
 ## Modern.js Runtime API
 

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

@@ -1,17 +1,21 @@
+---
+sidebar_position: 5
+---
+
 # Using Storybook
 
 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/use-micro-generator#storybook-debug)
+- [`modern dev`](/en/guide/command-preview#modern-dev)
 
 [Storybook](https://storybook.js.org/) is a tool dedicated to component debugging, providing around component development.
 
-* Develop UIs that are more durable
-* Test UIs with less effort and no flakes
-* Document UI for your team to reuse
-* Share how the UI actually works
-* Automate UI workflows
+- Develop UIs that are more durable
+- Test UIs with less effort and no flakes
+- Document UI for your team to reuse
+- Share how the UI actually works
+- Automate UI workflows
 
 So it is a complex and powerful tool.
 
@@ -21,8 +25,8 @@ The modular engineering solution is integrated with Storybook, so you can pretty
 
 Component code needs to be introduced during debugging code, and currently component code can be introduced in two ways:
 
-* Referencing the component product
-* Referencing component source code
+- Referencing the component product
+- Referencing component source code
 
 We recommend the first way of "**referencing component product**". Because it is almost close to the real usage scenario, not only can we debug the component functionality, but also verify the correctness of the build product.
 
@@ -36,9 +40,9 @@ If the TypeScript project `foo` exists.
 
 ```json package.json
 {
-    "name": "foo",
-    "main": "./dist/index.js",
-    "types": "./dist/types/index.d.ts"
+  "name": "foo",
+  "main": "./dist/index.js",
+  "types": "./dist/types/index.d.ts"
 }
 ```
 
@@ -49,9 +53,9 @@ values are real paths.
 
 ```json package.json
 {
-    "name": "foo",
-    "main": "./dist/index.js",
-    "types": "./dist/types/index.d.ts"
+  "name": "foo",
+  "main": "./dist/index.js",
+  "types": "./dist/types/index.d.ts"
 }
 ```
 
@@ -65,7 +69,6 @@ export const content = 'hello world';
 
 ---
 
-
 Make sure that the `paths` configuration pointing to the project root is set in `stories/tsconfig.json`.
 The `key` of `paths` is the same as the project name.
 
@@ -105,7 +108,7 @@ If, during development, you encounter a situation where the type definition is n
 
 For `pnpm` projects, `package.json` can be modified as follows.
 
-``` ts focus=4:7
+```ts focus=4:7
 {
     "name": "foo",
     "main": "./dist/index.js",
@@ -115,17 +118,16 @@ For `pnpm` projects, `package.json` can be modified as follows.
     }
 }
 ```
+
 > For the use of pnpm's `publishConfig`, you can read the following [link](https://pnpm.io/package_json#publishconfig).
 
 For npm and Yarn projects, the values of `types` of `package.json` can only be changed manually in **development phase** and **release phase**.
 
-
 So why is it possible to reference the product directly?
 
 1. the `modern build` command is executed automatically before the `modern dev storybook` command, ensuring the existence of the project build product.
 2. The project name is added as an alias inside Storybook to ensure that the path to the project's product can be parsed **according to `package.json`**.
 
-
 ### Referencing component source code
 
 Referencing component source code can be done by means of relative paths to:
@@ -146,7 +148,6 @@ So why is the source code approach not recommended?
 
 Not only is it impossible to verify that the component product is correct using the component source code, **but also some of the configurations supported by the module project for building the product cannot be fully translated into Storybook internal configuration**. If some of the configurations cannot be converted to each other, there will be unintended results during Storybook debugging.
 
-
 ## Configure Storybook
 
 ### Configuration file
@@ -155,12 +156,12 @@ Storybook is officially configured for projects through a folder called `.storyb
 
 For more information on how to use the various Storybook configuration files, see the following links:
 
-* [Configure Storybook](https://storybook.js.org/docs/react/configure/overview)
+- [Configure Storybook](https://storybook.js.org/docs/react/configure/overview)
 
 **But there are some limitations to Storybooking in a module project**:
 
-* It is currently not possible to change the location of the Story file, i.e., you cannot change the `stories` configuration in the `main.js` file.
-* Currently you cannot modify Webpack and Babel related configuration, i.e. you cannot modify `webpackFinal` and `babel` configuration in the `main.js` file.
+- It is currently not possible to change the location of the Story file, i.e., you cannot change the `stories` configuration in the `main.js` file.
+- Currently you cannot modify Webpack and Babel related configuration, i.e. you cannot modify `webpackFinal` and `babel` configuration in the `main.js` file.
 
 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.
 
@@ -170,18 +171,18 @@ In addition to the configuration file, the module engineering solution also prov
 
 The webpack configuration of Storybook can be modified via this configuration.
 
-* [`dev.storybook.webpack`](xxx)
+- [`dev.storybook.webpack`](xxx)
 
 ### Building Storybook Products
 
 In addition to Storybook debugging of components or common modules, you can also perform Storybook build tasks with the following commands.
 
-``` bash
+```bash
 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/command-preview#modern-build)
 
 After the build is complete, you can see the build product files in the `dist/storybook-static` directory.

package/docs/en/guide/best-practices/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Best practices",
+  "sidebar_position": 4
+}