@modern-js/main-doc 3.9.3 → 3.10.1

package/docs/en/guides/basic-features/output-files.mdx

@@ -113,7 +113,7 @@ export default {
   },
   html: {
     outputStructure: 'flat',
-  }
+  },
 };
 ```
 

package/docs/en/guides/basic-features/render/overview.mdx

@@ -8,21 +8,21 @@ Modern.js supports multiple rendering modes, and different rendering modes are s
 
 ## Rendering Mode Quick Reference
 
-| Rendering Mode | Characteristics | Use Cases |
-|----------------|-----------------|-----------|
-| **CSR** | Executes JavaScript in the browser to render pages | Applications with strong interactivity and low SEO requirements |
-| **SSR** | Pre-renders complete HTML pages on the server | Websites with high requirements for first-screen performance and SEO |
-| **Streaming SSR** | Renders and returns progressively, displaying initial UI faster | Applications requiring faster first-screen perception speed (**Default SSR mode**) |
-| **RSC** | Components render on the server, reducing client JS size; high cohesion between data and component logic, reducing state passing | Projects pursuing optimal performance and needing to reduce client-side code |
-| **SSG** | Generates static pages at build time, can be cached by CDN | Websites with relatively static content, such as blogs and documentation sites |
+| Rendering Mode    | Characteristics                                                                                                                  | Use Cases                                                                          |
+| ----------------- | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| **CSR**           | Executes JavaScript in the browser to render pages                                                                               | Applications with strong interactivity and low SEO requirements                    |
+| **SSR**           | Pre-renders complete HTML pages on the server                                                                                    | Websites with high requirements for first-screen performance and SEO               |
+| **Streaming SSR** | Renders and returns progressively, displaying initial UI faster                                                                  | Applications requiring faster first-screen perception speed (**Default SSR mode**) |
+| **RSC**           | Components render on the server, reducing client JS size; high cohesion between data and component logic, reducing state passing | Projects pursuing optimal performance and needing to reduce client-side code       |
+| **SSG**           | Generates static pages at build time, can be cached by CDN                                                                       | Websites with relatively static content, such as blogs and documentation sites     |
 
 ## Performance Comparison
 
-| Rendering Technology | Core Advantages | Main Bottlenecks |
-|---------------------|-----------------|------------------|
-| **SSR** | Server-side pre-rendering, beneficial for SEO | Must wait for all data to load before responding |
-| **Streaming SSR** | Renders and returns progressively, faster first screen | JS bundle size is still large |
-| **Streaming SSR + RSC** | Reduces client JS size | - |
+| Rendering Technology    | Core Advantages                                        | Main Bottlenecks                                 |
+| ----------------------- | ------------------------------------------------------ | ------------------------------------------------ |
+| **SSR**                 | Server-side pre-rendering, beneficial for SEO          | Must wait for all data to load before responding |
+| **Streaming SSR**       | Renders and returns progressively, faster first screen | JS bundle size is still large                    |
+| **Streaming SSR + RSC** | Reduces client JS size                                 | -                                                |
 
 ## How to Choose
 

package/docs/en/guides/basic-features/render/rsc.mdx

@@ -239,12 +239,12 @@ In RSC projects, you have two ways to fetch data: directly in Server Components,
 
 ### Comparison of Two Data Fetching Approaches
 
-| Feature | Fetching in Server Component | Fetching in Data Loader |
-| --- | --- | --- |
-| Avoid Request Waterfall | Requires manual optimization | ✅ Automatically parallel execution |
-| Component Cohesion | ✅ Data and UI in the same place | Data logic separated into separate files |
-| Maintainability | ✅ Easier to understand and maintain | Requires maintaining additional files |
-| Type Safety | ✅ Natural type inference | Requires manual type management |
+| Feature                 | Fetching in Server Component         | Fetching in Data Loader                  |
+| ----------------------- | ------------------------------------ | ---------------------------------------- |
+| Avoid Request Waterfall | Requires manual optimization         | ✅ Automatically parallel execution      |
+| Component Cohesion      | ✅ Data and UI in the same place     | Data logic separated into separate files |
+| Maintainability         | ✅ Easier to understand and maintain | Requires maintaining additional files    |
+| Type Safety             | ✅ Natural type inference            | Requires manual type management          |
 
 **Generally, we recommend fetching data in Server Components**, because waterfall requests have less performance impact on the server, and this approach makes components more cohesive, with data fetching logic and UI rendering in the same place, making it easier to understand and maintain. However, if your page has multiple independent data sources and you want to completely avoid request waterfall issues, Data Loader's parallel execution feature will be more advantageous.
 
@@ -268,7 +268,11 @@ In Modern.js RSC projects, Server Components can receive data returned by Data L
 
 ```tsx title="routes/user/page.tsx"
 // Server Component receives loaderData through props
-export default function UserPage({ loaderData }: { loaderData: { name: string } }) {
+export default function UserPage({
+  loaderData,
+}: {
+  loaderData: { name: string };
+}) {
   return <div>Welcome, {loaderData.name}</div>;
 }
 ```
@@ -276,7 +280,11 @@ export default function UserPage({ loaderData }: { loaderData: { name: string }
 ```tsx title="routes/user/page.tsx"
 'use client';
 // Client Component can also receive loaderData through props
-export default function UserPage({ loaderData }: { loaderData: { name: string } }) {
+export default function UserPage({
+  loaderData,
+}: {
+  loaderData: { name: string };
+}) {
   return <div>Welcome, {loaderData.name}</div>;
 }
 ```
@@ -515,7 +523,6 @@ When using React 19, you no longer need to use Helmet. We recommend directly usi
 
 import DeployTip from '@site-docs/components/rsc-deploy-tip';
 
-
 <DeployTip />
 
 ## Common Issues

package/docs/en/guides/basic-features/render/ssr-cache.mdx

@@ -193,9 +193,9 @@ When rendering cache is enabled, Modern.js identifies the cache status of the cu
 
 The `x-render-cache` header can have the following values:
 
-| Name    | Description                                      |
-| ------- | ------------------------------------------------ |
-| hit     | Cache hit, returned cache content                |
+| Name    | Description                                                                         |
+| ------- | ----------------------------------------------------------------------------------- |
+| hit     | Cache hit, returned cache content                                                   |
 | stale   | Cache hit, but data is stale, returned cache content and re-rendered asynchronously |
-| expired | Cache expired, re-rendered and returned new content |
-| miss    | Cache missed                                     |
+| expired | Cache expired, re-rendered and returned new content                                 |
+| miss    | Cache missed                                                                        |

package/docs/en/guides/basic-features/render/ssr.mdx

@@ -90,7 +90,7 @@ export async function loader({ params }) {
   const data = await res.json();
   return {
     message: data.message,
-  }
+  };
 }
 ```
 
@@ -125,11 +125,7 @@ const Page = () => {
   const undefinedVars = data.unDefined;
   const definedVars = data.defined;
 
-  return (
-    <div>
-      {isNode ? undefinedVars.msg : definedVars.msg}
-    </div>
-  );
+  return <div>{isNode ? undefinedVars.msg : definedVars.msg}</div>;
 };
 
 export default Page;
@@ -214,7 +210,7 @@ document.addEventListener('load', () => {
   console.log('document load');
 });
 
-export const doSomething = () => {}
+export const doSomething = () => {};
 ```
 
 Directly referencing this in a component will cause SSR to throw errors, even if you use environment variables to conditionally load the code. The side effects in the dependency will still execute.
@@ -226,8 +222,8 @@ export const Page = () => {
   if (process.env.MODERN_TARGET === 'browser') {
     doSomething();
   }
-  return <div>Hello World</div>
-}
+  return <div>Hello World</div>;
+};
 ```
 
 Modern.js supports distinguishing between SSR and CSR bundles by using `.server.` suffix files. You can create `.ts` and `.server.ts` files with the same name to create a proxy:
@@ -243,12 +239,12 @@ export const doSomething: any = () => {};
 Import `./a` in the file, and the SSR bundle will prioritize the `.server.ts` files, while the CSR bundle will prioritize the `.ts` files.
 
 ```tsx title="routes/page.tsx"
-import { doSomething } from './a'
+import { doSomething } from './a';
 
 export const Page = () => {
   doSomething();
-  return <div>Hello World</div>
-}
+  return <div>Hello World</div>;
+};
 ```
 
 ## Common Issues

package/docs/en/guides/basic-features/render/streaming-ssr.mdx

@@ -245,7 +245,8 @@ Set the header in your middleware to choose the behavior dynamically:
 ```ts title="middleware example"
 export const middleware = async (ctx, next) => {
   const ua = ctx.req.header('user-agent') || '';
-  const shouldWaitAll = /Lighthouse|Googlebot/i.test(ua) || ctx.req.path === '/marketing';
+  const shouldWaitAll =
+    /Lighthouse|Googlebot/i.test(ua) || ctx.req.path === '/marketing';
 
   // Write a boolean string: true -> onAllReady, false -> onShellReady
   ctx.req.headers.set('x-should-stream-all', String(shouldWaitAll));

package/docs/en/guides/basic-features/routes/config-routes.mdx

@@ -6,7 +6,6 @@ sidebar_position: 3
 
 By default, Modern.js recommends using [Convention Routes](./routes.mdx) as the way to define routes. At the same time, Modern.js also provides a config-based routing capability that can be used together with convention routes or used separately.
 
-
 ## When to Use Config Routes
 
 Config routes are particularly useful in the following scenarios:
@@ -22,27 +21,26 @@ Config routes are particularly useful in the following scenarios:
 In the `src` directory or each entry directory, you can define a `modern.routes.ts` file to configure routes:
 
 ```ts
-import { defineRoutes } from '@modern-js/runtime/config-routes'
+import { defineRoutes } from '@modern-js/runtime/config-routes';
 
 export default defineRoutes(({ route, layout, page, $ }, fileRoutes) => {
-  return [
-    route("home.tsx", "/"),
-  ]
-})
+  return [route('home.tsx', '/')];
+});
 ```
 
 ### Function Signature Description
 
 `defineRoutes` accepts a callback function with two parameters:
+
 1. `routeFunctions`: An object containing `route`, `layout`, `page`, `$` functions
 2. `fileRoutes`: An array of route configurations generated by convention routes
 
 Basic signature of route functions:
+
 - First parameter: File path relative to `modern.routes.ts`
 - Second parameter: Route path (optional, must be a string)
 - Third parameter: Array of child routes (optional)
 
-
 ## Route Functions
 
 Modern.js provides four main route configuration functions:
@@ -50,6 +48,7 @@ Modern.js provides four main route configuration functions:
 :::tip Path Description
 
 The first parameter (path) of all route functions is a **relative path**, which will be concatenated with the parent path to generate the final route path:
+
 - **Root path**: `"/"` or `""` represents the root path of the current level
 - **Relative path**: Child route paths will be concatenated relative to the parent path
 - **Dynamic path**: Use `:param` syntax to represent dynamic parameters
@@ -72,27 +71,28 @@ The `route` function is a general-purpose route configuration function that auto
 export default defineRoutes(({ route }, fileRoutes) => {
   return [
     // When no child routes, automatically generates page route
-    route("home.tsx", "/"),
-    route("about.tsx", "about"),
+    route('home.tsx', '/'),
+    route('about.tsx', 'about'),
 
     // When has child routes, automatically generates layout route
     // dashboard/layout.tsx needs to contain <Outlet> to render child routes
-    route("dashboard/layout.tsx", "dashboard", [
-      route("dashboard/overview.tsx", "overview"),  // Generated path: /dashboard/overview
-      route("dashboard/settings.tsx", "settings"),  // Generated path: /dashboard/settings
+    route('dashboard/layout.tsx', 'dashboard', [
+      route('dashboard/overview.tsx', 'overview'), // Generated path: /dashboard/overview
+      route('dashboard/settings.tsx', 'settings'), // Generated path: /dashboard/settings
     ]),
 
     // Dynamic routes
-    route("products/detail.tsx", "products/:id"),
+    route('products/detail.tsx', 'products/:id'),
 
     // Multiple paths pointing to the same component
-    route("user/profile.tsx", "user"),
-    route("user/profile.tsx", "profile"),
-  ]
-})
+    route('user/profile.tsx', 'user'),
+    route('user/profile.tsx', 'profile'),
+  ];
+});
 ```
 
 **Use cases**:
+
 - Quick route configuration without explicitly specifying page or layout
 - Simplify the complexity of route configuration
 
@@ -104,15 +104,16 @@ The `layout` function is specifically used to configure layout routes, always ge
 export default defineRoutes(({ layout, page }, fileRoutes) => {
   return [
     // Generate layout route with path "/auth", must contain child routes
-    layout("auth/layout.tsx", "auth", [
-      page("auth/login/page.tsx", "login"),      // Generated path: /auth/login
-      page("auth/register/page.tsx", "register"), // Generated path: /auth/register
+    layout('auth/layout.tsx', 'auth', [
+      page('auth/login/page.tsx', 'login'), // Generated path: /auth/login
+      page('auth/register/page.tsx', 'register'), // Generated path: /auth/register
     ]),
-  ]
-})
+  ];
+});
 ```
 
 **Use cases**:
+
 - Need to explicitly specify a component as a layout component
 - Provide common layout structure for multiple pages
 - Need to share navigation, sidebar and other UI components across multiple routes
@@ -124,15 +125,16 @@ The `page` function is specifically used to configure page routes, always genera
 ```ts
 export default defineRoutes(({ layout, page }, fileRoutes) => {
   return [
-    layout("dashboard/layout.tsx", "dashboard", [
-      page("dashboard/overview.tsx", "overview"),  // Generated path: /dashboard/overview
-      page("dashboard/settings.tsx", "settings"),  // Generated path: /dashboard/settings
+    layout('dashboard/layout.tsx', 'dashboard', [
+      page('dashboard/overview.tsx', 'overview'), // Generated path: /dashboard/overview
+      page('dashboard/settings.tsx', 'settings'), // Generated path: /dashboard/settings
     ]),
-  ]
-})
+  ];
+});
 ```
 
 **Use cases**:
+
 - Need to explicitly specify a component as a page component
 - Ensure the component does not contain `<Outlet>` child component rendering
 - Provide clearer semantic expression
@@ -144,16 +146,17 @@ The `$` function is specifically used to configure wildcard routes for handling
 ```ts
 export default defineRoutes(({ layout, page, $ }, fileRoutes) => {
   return [
-    layout("blog/layout.tsx", "blog", [
-      page("blog/page.tsx", ""),                    // Generated path: /blog
-      page("blog/[id]/page.tsx", ":id"),            // Generated path: /blog/:id
-      $("blog/$.tsx", "*"),                         // Wildcard route, matches all unmatched paths under /blog
+    layout('blog/layout.tsx', 'blog', [
+      page('blog/page.tsx', ''), // Generated path: /blog
+      page('blog/[id]/page.tsx', ':id'), // Generated path: /blog/:id
+      $('blog/$.tsx', '*'), // Wildcard route, matches all unmatched paths under /blog
     ]),
-  ]
-})
+  ];
+});
 ```
 
 **Use cases**:
+
 - Custom 404 pages
 - Handle all unmatched requests under specific paths
 
@@ -161,7 +164,6 @@ export default defineRoutes(({ layout, page, $ }, fileRoutes) => {
 The `$` function has the same functionality as the `$.tsx` file in convention routes, used to catch unmatched route requests.
 :::
 
-
 ## Configuring Routes
 
 ### Basic Example
@@ -170,11 +172,11 @@ The `$` function has the same functionality as the `$.tsx` file in convention ro
 export default defineRoutes(({ page }, fileRoutes) => {
   return [
     // Use page function to explicitly specify page route
-    page("home.tsx", "/"),
-    page("about.tsx", "about"),
-    page("contact.tsx", "contact"),
-  ]
-})
+    page('home.tsx', '/'),
+    page('about.tsx', 'about'),
+    page('contact.tsx', 'contact'),
+  ];
+});
 ```
 
 ### Routes Without Path
@@ -186,15 +188,16 @@ export default defineRoutes(({ layout, page }, fileRoutes) => {
   return [
     // Use layout function to explicitly specify layout route
     // auth/layout.tsx needs to contain <Outlet> to render child routes
-    layout("auth/layout.tsx", [
-      page("login/page.tsx", "login"),
-      page("register/page.tsx", "register"),
+    layout('auth/layout.tsx', [
+      page('login/page.tsx', 'login'),
+      page('register/page.tsx', 'register'),
     ]),
-  ]
-})
+  ];
+});
 ```
 
 The above configuration will generate:
+
 - `/login` → `auth/layout.tsx` + `login/page.tsx`
 - `/register` → `auth/layout.tsx` + `register/page.tsx`
 
@@ -203,14 +206,13 @@ The above configuration will generate:
 ```ts
 export default defineRoutes(({ page }, fileRoutes) => {
   return [
-    page("user.tsx", "user"),
-    page("user.tsx", "profile"),
-    page("user.tsx", "account"),
-  ]
-})
+    page('user.tsx', 'user'),
+    page('user.tsx', 'profile'),
+    page('user.tsx', 'account'),
+  ];
+});
 ```
 
-
 ### Dynamic Routes
 
 Config routes support dynamic route parameters:
@@ -219,15 +221,14 @@ Config routes support dynamic route parameters:
 export default defineRoutes(({ page }, fileRoutes) => {
   return [
     // Required parameter
-    page("blog/detail.tsx", "blog/:id"),
+    page('blog/detail.tsx', 'blog/:id'),
 
     // Optional parameter
-    page("blog/index.tsx", "blog/:slug?"),
-  ]
-})
+    page('blog/index.tsx', 'blog/:slug?'),
+  ];
+});
 ```
 
-
 ## Automatic Route-Related File Discovery
 
 Config routes automatically discover component-related files without manual configuration. For any component file specified in `modern.routes.ts`, Modern.js will automatically find the following related files:
@@ -236,10 +237,10 @@ Config routes automatically discover component-related files without manual conf
 // modern.routes.ts
 export default defineRoutes(({ route }, fileRoutes) => {
   return [
-    route("pages/profile.tsx", "profile"),
-    route("pages/user/detail.tsx", "user/:id"),
-  ]
-})
+    route('pages/profile.tsx', 'profile'),
+    route('pages/user/detail.tsx', 'user/:id'),
+  ];
+});
 ```
 
 Modern.js will automatically find and load:

package/docs/en/guides/basic-features/testing/playwright.mdx

@@ -6,7 +6,13 @@ To use Playwright in Modern.js, you need to install the dependencies first. You
 
 import { PackageManagerTabs } from '@theme';
 
-<PackageManagerTabs command={{ npm: "npm init playwright", yarn: "yarn create playwright", pnpm: "pnpm create playwright" }} />
+<PackageManagerTabs
+  command={{
+    npm: 'npm init playwright',
+    yarn: 'yarn create playwright',
+    pnpm: 'pnpm create playwright',
+  }}
+/>
 
 The above commands will automatically install Playwright dependencies and help you install and configure it in your project through a series of prompts, including adding a `playwright.config.ts` file.
 
@@ -74,18 +80,18 @@ export default Index;
 Next, add test cases to ensure the links on your pages work properly.
 
 ```ts title="tests/example.spec.ts"
-import { test, expect } from '@playwright/test'
+import { test, expect } from '@playwright/test';
 
 test('should navigate to the about page', async ({ page }) => {
   // Start from the index page (the baseURL is set via the webServer in the playwright.config.ts)
-  await page.goto('http://localhost:8080/')
+  await page.goto('http://localhost:8080/');
   // Find an element with the text 'About' and click on it
-  await page.click('text=About')
+  await page.click('text=About');
   // The new URL should be "/about" (baseURL is used there)
-  await expect(page).toHaveURL('http://localhost:8080/about')
+  await expect(page).toHaveURL('http://localhost:8080/about');
   // The new page should contain an h1 with "About"
-  await expect(page.locator('h1')).toContainText('About')
-})
+  await expect(page.locator('h1')).toContainText('About');
+});
 ```
 
 ## Run Test Cases
@@ -108,4 +114,4 @@ Running 3 tests using 3 workers
 To open last HTML report run:
 
   npx playwright show-report
-```
+```

package/docs/en/guides/basic-features/testing/rstest.mdx

@@ -84,9 +84,9 @@ test('Page', async () => {
     </Router>,
   );
 
-  await expect.element(
-    page.getByRole('heading', { level: 1, name: 'Home' }),
-  ).toBeVisible();
+  await expect
+    .element(page.getByRole('heading', { level: 1, name: 'Home' }))
+    .toBeVisible();
 });
 ```
 
@@ -181,12 +181,14 @@ First install and use the migrate-to-rstest skill. If it is not installed, insta
 npx skills add rstackjs/agent-skills --skill migrate-to-rstest
 
 Follow the migrate-to-rstest skill instructions and the official Rstest migration guides:
+
 - Jest: https://rstest.rs/guide/migration/jest
 - Vitest: https://rstest.rs/guide/migration/vitest
 
 Modern.js-specific requirement:
+
 - Install and use @modern-js/adapter-rstest together with @rstest/core.
 - Create or update rstest.config.ts to import withModernConfig from @modern-js/adapter-rstest.
 - Reuse the Modern.js app configuration with extends: withModernConfig().
 - Do not replace this with a plain Rstest config unless the project explicitly does not need Modern.js config integration.`}
-/>
+  />

package/docs/en/guides/get-started/ai-coding-agents.mdx

@@ -15,10 +15,10 @@ AI agents use them to get APIs, config, and conventions that exactly match your
 
 ## AGENTS.md
 
-`AGENTS.md` gives AI coding agents project-level guidance — telling them to read the bundled docs before making changes and to follow Modern.js conventions. A `CLAUDE.md` is generated alongside it, reusing the same guidance for Claude Code via the `@AGENTS.md` import.
+`AGENTS.md` gives AI coding agents project-level guidance — telling them to read the bundled docs before making changes and to follow Modern.js conventions.
 
-- **New projects**: `npx @modern-js/create` generates both files by default; pass `--no-agents-md` to skip them.
-- **Existing projects**: run `npx @modern-js/create --agents-md-only` at the project root to create or update them. Re-run it any time; your own additions are preserved.
+- **New projects**: `npx @modern-js/create` generates `AGENTS.md` by default; pass `--no-agents-md` to skip it.
+- **Existing projects**: run `npx @modern-js/create --agents-md-only` at the project root to create or update `AGENTS.md`. Re-run it any time; your own additions are preserved.
 
 Modern.js only maintains the content inside the `<!-- BEGIN:modernjs-agent-rules -->` markers in `AGENTS.md`; anything you write outside them is left untouched.
 
@@ -35,9 +35,9 @@ Use it when you need content beyond the bundled docs — just let your agent ret
 
 Skills are on-demand AI capabilities following the [Agent Skills open standard](https://github.com/vercel-labs/skills). User-facing Skills:
 
-| Skill | Identifier | Description |
-|---|---|---|
-| Upgrade to v3 | `modernjs-migrate-to-v3` | Migrate a v2 app to v3: safe rewrites + manual checklist + migration report |
+| Skill           | Identifier                | Description                                                                                     |
+| --------------- | ------------------------- | ----------------------------------------------------------------------------------------------- |
+| Upgrade to v3   | `modernjs-migrate-to-v3`  | Migrate a v2 app to v3: safe rewrites + manual checklist + migration report                     |
 | Enable features | `modernjs-feature-enable` | Enable BFF / SSG / styled-components for v3 apps, and scaffold Tailwind CSS / custom Web Server |
 
 > Skills are not force-installed or implicitly installed — you install them explicitly. RSC and micro-frontend setups are configuration or architecture decisions, not one-click `modernjs-feature-enable` actions.

package/docs/en/guides/get-started/introduction.mdx

@@ -39,4 +39,3 @@ In addition, Modern.js provides richer server-side features, including comprehen
 ### Remix
 
 Pelease refer to [Modern.js vs Remix](https://github.com/web-infra-dev/modern.js/discussions/4872).
-

package/docs/en/guides/topic-detail/module-federation/deploy.mdx

@@ -63,9 +63,9 @@ At this point, the `publicPath` defined in the producer's build output `mf-manif
     "name": "remote",
     "publicPath": "https://my-remote-module/"
   },
-  "shared": [ /* xxx */ ],
+  "shared": [/* xxx */],
   "remotes": [],
-  "exposes": [ /* xxx */ ]
+  "exposes": [/* xxx */]
 }
 ```
 

package/docs/en/guides/topic-detail/module-federation/introduce.mdx

@@ -33,4 +33,3 @@ For more details, refer to [Using Module Federation](/guides/topic-detail/module
 Module Federation 2.0 offers the [Bridge](https://module-federation.io/practice/bridge/overview.html) capability to load application-level modules.
 
 Modern.js, based on Bridge and its internal implementation, provides APIs to easily export application-level modules. For more details, refer to [Application-Level Modules](/guides/topic-detail/module-federation/application).
-

package/docs/en/guides/upgrade/config.mdx

@@ -22,6 +22,18 @@ server: {
 }
 ```
 
+### dev.lazyCompilation
+
+**Change**: The default value in development has changed. Pure CSR and streaming SSR applications enable lazy compilation by default with `{ imports: true, entries: false }`; applications using string SSR, RSC or SSG keep it disabled by default. This only affects development and does not change production build output.
+
+**Migration Example**: To keep the 2.0 behavior, disable it explicitly:
+
+```typescript
+dev: {
+  lazyCompilation: false;
+}
+```
+
 ## html
 
 ### html.appIcon

package/docs/en/guides/upgrade/other.mdx

@@ -22,10 +22,10 @@ If your project's deployment configuration specifies a particular entry file nam
 
 Modern.js 3.0 has adjusted some runtime paths, and related import paths need to be updated. The path mapping is as follows:
 
-| Old Path | New Path | Description |
-|---------|---------|------|
-| `@modern-js/runtime/bff` | `@modern-js/plugin-bff/runtime` | BFF runtime path |
-| `@modern-js/runtime/server` | `@modern-js/server-runtime` | Server-side runtime path |
+| Old Path                    | New Path                        | Description              |
+| --------------------------- | ------------------------------- | ------------------------ |
+| `@modern-js/runtime/bff`    | `@modern-js/plugin-bff/runtime` | BFF runtime path         |
+| `@modern-js/runtime/server` | `@modern-js/server-runtime`     | Server-side runtime path |
 
 ## useRuntimeContext Deprecated
 

package/docs/en/guides/upgrade/tailwindcss.mdx

@@ -89,4 +89,3 @@ Change the CSS import method to the `@tailwind` directive approach.
 @tailwind components;
 @tailwind utilities;
 ```
-