@modern-js/main-doc 2.1.0 → 2.2.0

package/en/configure/app/bff/proxy.mdx

@@ -0,0 +1,76 @@
+---
+sidebar_label: proxy
+---
+
+# bff.proxy
+
+- Type: `Record<string, string>`
+- Default: `{}`
+
+:::caution Caution
+First you need to enable the "BFF" function using [new](/apis/app/commands/new) command.
+
+:::
+
+With simple configuration, no code is required, Modern.js automatically forwards requests. Requests sent to Modern.js BFF server are proxied to the specified service.
+
+BFF Proxy uses the powerful [http-proxy-middleware](https://github.com/chimurai/http-proxy-middleware), and if you need more advanced usage, you can check its [documentation](https://github.com/chimurai/http-proxy-middleware#options).
+
+Add the following configuration to `modern.server-runtime.config.ts`, you can turn on the proxy:
+
+```ts title="modern.server-runtime.config.ts"
+import { defineConfig } from '@modern-js/app-tools/server';
+export default defineConfig({
+  bff: {
+    proxy: {
+      '/api': 'https://cnodejs.org',
+    },
+  },
+});
+```
+
+Assuming that the starting Modern.js BFF server's service address is `localhost:8080`, all requests whose path starts with `api` will be intercepted, such as requests sent to `localhost:8080/api/v1/topics` will be proxied to `https://cnodejs.org/api/v1/topics`.
+
+You can do path rewriting, such as proxying requests sent to `localhost:8080/api/topics` to `https://cnodejs.org/api/v1/topics`.
+
+```js title="modern.server-runtime.config.js"
+import { defineConfig } from '@modern-js/app-tools/server';
+export default defineConfig({
+  bff: {
+    proxy: {
+      '/api': {
+        target: 'https://cnodejs.org',
+        pathRewrite: { '/api/topics': '/api/v1/topics' },
+        changeOrigin: true,
+      },
+    },
+  },
+});
+```
+
+Unlike [dev.proxy](/configure/app/dev/proxy), the proxy described in this section only works on requests entering the BFF/API service; at the same time, this configuration can be used not only in the development environment, but also in the production environment. The corresponding request will also be proxied in the production environment.
+
+## Common usage
+
+### Solve interface cross-domain problems
+
+In the process of project development, because web pages and interface services are not deployed under the same domain name, cross-domain problems are often encountered.
+
+There are many ways to solve cross-domain problems, and here we use `bff.proxy` to easily solve cross-domain problems.
+
+:::info
+In BFF proxy mode, if you do not need to write the BFF interface, the API directory can be deleted; at this time, BFF proxy will still be enabled.
+
+:::
+
+As shown below, in the `modern.server-runtime.config.js`, write the following configuration; we send all web pages to the same domain that request proxies starting with `/api` to another domain's service.
+
+```ts title="modern.server-runtime.config.ts"
+export default defineServerConfig({
+  bff: {
+    proxy: {
+      '/api': 'https://cnodejs.org',
+    },
+  },
+};
+```

package/en/configure/app/builder-plugins.mdx

@@ -0,0 +1,71 @@
+---
+title: builderPlugins
+sidebar_position: 10
+---
+# builderPlugins
+
+- Type: `BuilderPlugin[]`
+- Default: `[]`
+
+Used to configure the Modern.js Builder plugin.
+
+Modern.js Builder is the build engine of Modern.js, please read [Builder](/guides/basic-features/builder) for background. If you want to know how to write Builder plugins, you can refer to [Modern.js Builder - Introduce to Plugin](https://modernjs.dev/builder/en/plugins/introduction.html).
+
+## Precautions
+
+This option **is used to configure the Modern.js Builder plugins**. If you need to configure other types of plugins, please select the corresponding configs:
+
+- Use [plugins](docs/configure/app/builder-plugins) to configure Modern.js framework plugins.
+- Use [tools.webpack](/configure/app/tools/webpack) or [tools.webpackChain](/configure/app/tools/webpack-chain) to configure webpack plugins.
+- Use [tools.babel](/configure/app/tools/babel) to configure babel plugins.
+
+## When to use
+
+In most scenarios, we recommend you to use the Modern.js framework plugin, which can be registered through the [plugins](docs/configure/app/plugins) config. Because the API provided by the framework plugin is richer and more capable, while the API provided by the Builder plugin can only be used to build scenes.
+
+When you need to reference some existing Builder plugins (and there is no related capability in Modern.js), or reuse Builder plugins between different frameworks, you can use the `builderPlugins` field to register them.
+
+## Example
+
+Below is an example of using the Builder plugin.
+
+### Using plugins on npm
+
+To use a plugin on npm, you need to install the plugin through the package manager and import it.
+
+```ts title="modern.config.ts"
+import myBuilderPlugin from 'my-builder-plugin';
+
+export default defineConfig({
+  builderPlugins: [myBuilderPlugin()],
+});
+```
+
+### Using local plugins
+
+Use the plugin in the local code repository, you can import it directly through the relative path import.
+
+```ts title="modern.config.ts"
+import myBuilderPlugin from './plugin/myBuilderPlugin';
+
+export default defineConfig({
+  builderPlugins: [myBuilderPlugin()],
+});
+```
+
+### Plugin configuration items
+
+If the plugin provides some custom configuration options, you can pass in the configuration through the parameters of the plugin function.
+
+```ts title="modern.config.ts"
+import myBuilderPlugin from 'my-builder-plugin';
+
+export default defineConfig({
+  builderPlugins: [
+    myBuilderPlugin({
+      foo: 1,
+      bar: 2,
+    }),
+  ],
+});
+```

package/en/configure/app/deploy/microFrontend.mdx

@@ -0,0 +1,53 @@
+---
+sidebar_label: microFrontend
+---
+
+# deploy.microFrontend
+
+- Type: `object`
+- Default: `{ enableHtmlEntry: true, externalBasicLibrary: false }`
+
+```ts
+interface MicroFrontend {
+  enableHtmlEntry?: boolean;
+  externalBasicLibrary?: boolean;
+  moduleApp?: string;
+}
+```
+
+Developers can use the `deploy.microFrontend` to configure micro-frontend sub-application information.
+
+:::caution
+Enable the "Micro Frontend" features through `pnpm run new` first.
+
+:::
+
+## Example
+
+```ts
+export default defineConfig({
+  deploy: {
+    microFrontend: {
+      enableHtmlEntry: true,
+    },
+  },
+});
+```
+
+## Configuration
+
+### enableHtmlEntry
+
+- Type: `boolean`
+- Default: `true`
+
+Whether to enable the html entry, the default is `true`, the sub-application is built into the `HTML` mode, Garfish supports the `html` entry, you can turn on the open option, experience the corresponding features, and directly point the sub-application entry to the HTML entry when it is the HTML entry. Just point to the html of the sub-application
+
+Set it to `false` to indicate that the sub-application is built as `js`. After the sub-application is built as `js`, it cannot run independently. When it is a `JS` entry, point the entry file of the sub-application to the `JS` of the sub-application.
+
+### externalBasicLibrary
+
+- Type: `boolean`
+- Default: `false`
+
+Whether the `external` base library, when set to `true`, the current child application will be `external`: `react`, `react-dom`, Modern.js main application will automatically `setExternal` these two base libraries, if other types of frameworks Please add `react`, `react-dom` dependencies through `Garfish.setExternal`.

package/en/configure/app/dev/proxy.mdx

@@ -0,0 +1,9 @@
+---
+sidebar_label: proxy
+---
+
+# dev.proxy
+
+import GlobalProxyConfig from "@site-docs-en/components/global-proxy-config"
+
+<GlobalProxyConfig />

package/en/configure/app/output/ssg.mdx

@@ -0,0 +1,196 @@
+---
+sidebar_label: ssg
+---
+
+# output.ssg
+
+- Type: `boolean` | `object` | `function`
+- Default: `undefined`
+
+Enable the SSG for **Self-controlled Routing** or **Conventional Routing**.
+
+:::info
+For more routes detail, see [routes](/guides/basic-features/routes)。
+
+:::
+
+## Example
+
+### Single Entry
+
+When the configuration is set to `true`, the SSG of all entries will be enabled by default.
+
+For **self-controlled routing**, the root route of the entry will be rendered. For **convention routing**, every route in the entry will be rendered.
+
+For example, the `src/` directory has the following file structure that satisfies **conventional routing**:
+
+```bash
+.
+├── src
+│   └── routes
+│       ├── layout.tsx
+│       ├── page.tsx
+│       └── user
+│           ├── layout.tsx
+│           ├── page.tsx
+│           └── profile
+│               └── page.tsx
+```
+
+Make the following config in `modern.config.[tj]s`:
+
+```ts
+export default defineConfig({
+  output: {
+    ssg: true,
+  },
+});
+```
+
+After executing `pnpm build` to build the application. The `dist/` directory will generate three HTML for each of the three routes (only one HTML if SSG not enabled), and all HTML has been rendered.
+
+For example the following **self-controlled routing**:
+
+import SelfRouteExample from "@site-docs/components/self-route-example";
+
+<SelfRouteExample />
+
+Also using the above configuration, after executing `pnpm run build`, only the entry route `/` will generate the rendered HTML.
+
+### Multi Entries
+
+`output.ssg` can also be configured according to the entries, and the rules that the configuration takes effect are also determined by the entries routing method.
+
+例如以下目录结构：
+
+```bash
+。
+├── src
+│   ├── entryA
+│   │   └── routes
+│   │       ├── layout.tsx
+│   │       ├── page.tsx
+│   │       └── user
+│   │           ├── layout.tsx
+│   │           ├── page.tsx
+│   │           └── profile
+│   │               └── page.tsx
+│   └── entryB
+│       └── App.tsx
+```
+
+By default, all entryA entrances are rendered at build time after setting `output.ssg` to `true`. You can configure `false` to cancel the default behavior of the specified entries. For example, to cancel the rendering of the `entryA` at build time:
+
+```js
+export default defineConfig({
+  output: {
+    ssg: {
+      entryA: true,
+      entryB: false,
+    },
+  },
+});
+```
+
+### Configure Route
+
+As mentioned above, **Self-Controlled Routing** only enables SSG configuration for entries route by default.
+
+Set specific routes in `output.ssg` can tell Modern.js to enable the SSG of these client side routes. For example, the content of the above `src/App.tsx` file is:
+
+<SelfRouteExample />
+
+
+When set like this in `modern.config.[jt]s`, the `/about` route will also enable SSG:
+
+```js
+export default defineConfig({
+  output: {
+    ssg: {
+      routes: ['/', '/about'],
+    },
+  },
+});
+```
+
+Modern.js will automatically concat the complete URL according to the entry and hand it over to the SSG plugin to complete the rendering.
+
+Request headers can also be configured for specific entries or routes, for example:
+
+```js
+export default defineConfig({
+  output: {
+    ssg: {
+      headers: {},
+      routes: [
+        '/',
+        {
+          url: '/about',
+          headers: {},
+        },
+      ],
+    },
+  },
+});
+```
+
+:::info
+The `headers` set in the route override the `headers` set in the entry.
+
+:::
+
+### Prevent Default
+
+By default, **Conventional Routing** all turn on SSG. Modern.js provides another field to prevent the default SSG behavior.
+
+For example, the following directory structure ，`/`、`/user` and `/user/profle` all have SSG enabled:
+
+```bash
+.
+├── src
+│   └── routes
+│       ├── layout.tsx
+│       ├── page.tsx
+│       └── user
+│           ├── layout.tsx
+│           ├── page.tsx
+│           └── profile
+│               └── page.tsx
+```
+
+You can set this to disable the default behavior of a client-side route:
+
+```js
+export default defineConfig({
+  output: {
+    preventDefault: ['/user'],
+  },
+});
+```
+
+### Dynamic Params
+
+Some routes may be dynamic, such as the `/user/:id` in a self-controlled route or the route generated by the `user/[id]/page.tsx` file in a conventional route.
+
+configure specific parameters in `output.ssg` to render the route of the specified parameters, for example:
+
+```js
+export default defineConfig({
+  output: {
+    ssg: {
+      routes: [
+        {
+          url: '/user/:id',
+          params: [
+            {
+              id: 'modernjs',
+            },
+          ],
+        },
+      ],
+    },
+  },
+});
+```
+
+The features of dynamic routing and SSG is useful when generating static pages in real time based on CMS system.

package/en/configure/app/plugins.mdx

@@ -0,0 +1,81 @@
+---
+title: plugins
+sidebar_position: 9
+---
+# plugins
+
+- Type: `CliPlugin[]`
+- Default: `[]`
+
+Used to configure custom Modern.js framework plugins.
+
+For the way to write custom plugins, please refer to [How to Write Plugins](/guides/topic-detail/framework-plugin/implement).
+
+## Precautions
+
+This config **is used to configure the Modern.js framework plugin**. If you need to configure other types of plugins, please select the corresponding configs:
+
+- Use [builderPlugins](docs/configure/app/builder-plugins) to configure Modern.js Builder plugins.
+- Use [tools.webpack](/configure/app/tools/webpack) or [tools.webpackChain](/configure/app/tools/webpack-chain) to configure webpack plugins.
+- Use [tools.babel](/configure/app/tools/babel) to configure babel plugins.
+
+## Plugin type
+
+There are three different type of framework plugins built into the Modern.js:
+
+- `CLI Plugin`，for local development, compilation and build phases, can extend various capabilities on the command line and compilation phases.
+- `Server Plugin`，for server-level.
+- `Runtime Plugin`，for runtime.
+
+The ability to customize CLI plugins is currently open Modern.js, and the Server plugin and Runtime plugin will be available in the future.
+
+## Plugin execution order
+
+By default, custom plugins are executed sequentially in the order of an array of `plugins`, Modern.js built-in plugins are executed earlier than custom plugins.
+
+When the plugin uses related fields that control the order, such as `pre` and `post`, the execution order will be adjusted based on the declared fields, see [Relationship between plugins](/guides/topic-detail/framework-plugin/relationship).
+
+## Example
+
+Below is an example of using the CLI plugin.
+
+### Using plugins on npm
+
+To use the plugin on npm, you need to install the plugin through the package manager and import it.
+
+```ts title="modern.config.ts"
+import myPlugin from 'my-plugin';
+
+export default defineConfig({
+  plugins: [myPlugin()],
+});
+```
+
+### Use local plugins
+
+Using the plugin in the local code repository, you can import it directly through the relative path import.
+
+```ts title="modern.config.ts"
+import myPlugin from './config/plugin/myPlugin';
+
+export default defineConfig({
+  plugins: [myPlugin()],
+});
+```
+
+### Plugin configuration
+
+If the plugin provides some custom configuration options, you can pass in the configuration through the parameters of the plugin function.
+
+```ts title="modern.config.ts"
+import myPlugin from 'my-plugin';
+
+export default defineConfig({
+  plugins: [
+    myPlugin({
+      foo: 1,
+      bar: 2,
+    }),
+  ],
+});
+```