@bleedingdev/modern-js-app-tools 3.5.0-ultramodern.99 → 3.8.1-ultramodern.2

package/docs/guides/advanced-features/bff/frameworks.mdx

@@ -1,131 +0,0 @@
----
-sidebar_position: 3
-title: Runtime Framework
----
-
-# Runtime Framework
-
-Modern.js supports two BFF runtime frameworks:
-
-- `effect` (default): use [Effect HttpApi](https://effect.website/) runtime from `api/index`.
-- `hono`: use file-convention BFF handlers from `api/lambda/**`.
-
-`effect` and `hono` are strict runtime modes. There is no automatic fallback between them.
-
-::::info
-This page documents generic Modern.js runtime support. Generated UltraModern
-workspaces always use the `effect` runtime with
-`bff.effect.strictEffectApproach: true`. Add or change generated UltraModern
-HTTP API work through `shared/api.ts` and `api/index.ts`; do not add
-Hono/file-convention handlers, raw request parsing, or manual `Response`
-construction inside those workspaces.
-::::
-
-## Switch to Effect runtime
-
-```ts title="modern.config.ts"
-import { bffPlugin } from '@modern-js/plugin-bff';
-import { defineConfig } from '@modern-js/app-tools';
-
-export default defineConfig({
-  plugins: [bffPlugin()],
-  bff: {
-    runtimeFramework: 'effect',
-    effect: {
-      entry: './api/index',
-      strictEffectApproach: true,
-      openapi: {
-        path: '/openapi.json',
-      },
-    },
-  },
-});
-```
-
-Define a shared Effect HttpApi contract (for type-safe client + server):
-
-```ts title="shared/api.ts"
-import {
-  HttpApi,
-  HttpApiEndpoint,
-  HttpApiGroup,
-  Schema,
-} from '@modern-js/plugin-bff/effect-client';
-
-export const bffApi = HttpApi.make('MyApi').add(
-  HttpApiGroup.make('hello').add(
-    HttpApiEndpoint.get('ping', '/ping', {
-      success: Schema.String,
-    }),
-  ),
-);
-```
-
-Implement your Effect API entry at `api/index.ts`:
-
-```ts title="api/index.ts"
-import {
-  Schema,
-  Effect,
-  HttpApiBuilder,
-  defineEffectBff,
-  Layer,
-  ServiceMap,
-} from '@modern-js/plugin-bff/effect-server';
-import { bffApi } from '../shared/api';
-
-class GreetingUnavailableError extends Schema.TaggedError<GreetingUnavailableError>()(
-  'GreetingUnavailableError',
-  {
-    message: Schema.String,
-  },
-) {}
-
-class GreetingService extends ServiceMap.Service<GreetingService>()('GreetingService', {
-  make: Effect.succeed({
-    hello: Effect.fn('GreetingService.hello')(function* () {
-      if (Date.now() < 0) {
-        return yield* Effect.fail(
-          new GreetingUnavailableError({
-            message: 'Greeting service is unavailable',
-          }),
-        );
-      }
-      return yield* Effect.succeed('pong');
-    }),
-  }),
-}) {
-  static readonly layer = Layer.effect(this, this.make);
-}
-
-const group = HttpApiBuilder.group(bffApi, 'hello', handlers =>
-  handlers.handle('ping', () =>
-    GreetingService.use(service => service.hello()).pipe(
-      Effect.catchTag('GreetingUnavailableError', error =>
-        Effect.succeed(error.message),
-      ),
-    ),
-  ),
-);
-
-const layer = HttpApiBuilder.layer(bffApi).pipe(
-  Layer.provide(group),
-  Layer.provide(GreetingService.layer),
-);
-
-export default defineEffectBff({ api: bffApi, layer });
-```
-
-Call Effect endpoints from browser code via `@api/index`:
-
-```ts title="src/routes/page.tsx"
-import api from '@api/index';
-
-const response = await api.client.hello.ping({});
-```
-
-The `api.client.*` surface is materialized by the BFF loader for `@api/index` imports. Do not import `api/index` directly and expect `client` to run in server code, scripts, or tests; direct entry imports expose the server runtime definition, and `client` is only a typed placeholder there.
-
-import Hono from '@site-docs-en/components/hono';
-
-<Hono />

package/docs/guides/advanced-features/bff/upload.mdx

@@ -1,7 +0,0 @@
-# File Upload
-
-BFF combined with runtime framework provides file upload capabilities, supporting integrated calls and pure function manual calls.
-
-import BffUpload from '@site-docs-en/components/bff-upload';
-
-<BffUpload />

package/docs/guides/advanced-features/international/_meta.json

@@ -1,10 +0,0 @@
-[
-  "quick-start",
-  "configuration",
-  "locale-detection",
-  "resource-loading",
-  "routing",
-  "api",
-  "advanced",
-  "best-practices"
-]

package/docs/guides/advanced-features/international/configuration.mdx

@@ -1,222 +0,0 @@
----
-title: Configuration
----
-
-# Configuration
-
-Plugin configuration is split between two files, each with a different responsibility:
-
-| File | Purpose |
-| --- | --- |
-| `modern.config.ts` | Basic plugin settings, read during build/startup |
-| `src/modern.runtime.ts` | i18next initialization options, read at runtime |
-
-:::warning Function values can only be configured at runtime
-`modern.config.ts` runs at build time and cannot serialize functions. SDK loaders, custom detection functions, and similar function values must be placed in `modern.runtime.ts`.
-:::
-
-## Configuration Ownership
-
-| Configuration | Where to configure |
-| --- | --- |
-| `localeDetection` (language detection, path redirects, etc.) | `modern.config.ts` |
-| `backend` (resource paths, SDK declaration, etc.) | `modern.config.ts` |
-| `i18nInstance` | `modern.runtime.ts` |
-| `initOptions` (`fallbackLng`, `ns`, and other i18next options) | `modern.runtime.ts` |
-| The actual `backend.sdk` loader function | `modern.runtime.ts` |
-
-## CLI Configuration
-
-```ts title="modern.config.ts"
-import { appTools, defineConfig } from '@modern-js/app-tools';
-import { i18nPlugin } from '@modern-js/plugin-i18n';
-
-export default defineConfig({
-  plugins: [
-    appTools(),
-    i18nPlugin({
-      localeDetection: { ... },
-      backend: { ... },
-    }),
-  ],
-});
-```
-
-### localeDetection Options
-
-| Field | Type | Default | Description |
-| --- | --- | --- | --- |
-| `languages` | `string[]` | `[]` | Supported language list |
-| `fallbackLanguage` | `string` | `''` | Fallback language when detection fails |
-| `localePathRedirect` | `boolean` | `false` | Handles URL locale prefix recognition, redirects, and switching. See [Routing Integration](./routing.md#enable-locale-path-prefixes) |
-| `localisedUrls` | `boolean \| Record<string, Record<string, string>>` | Prefix-only behavior | Localised route path map. Only a non-empty map enables translated path segments; omitted, `true`, `false`, and `{}` keep locale prefixes without translating path segments. |
-| `i18nextDetector` | `boolean` | `false` | Enables the i18next detector (Cookie / Header, etc.) |
-| `detection` | `LanguageDetectorOptions` | - | Detailed i18next detector configuration. See [Locale Detection](./locale-detection.md) |
-| `ignoreRedirectRoutes` | `string[] \| Function` | - | Routes that skip redirects. See [Locale Detection](./locale-detection.md#ignoreredirectroutes) |
-| `localeDetectionByEntry` | `Record<string, ...>` | - | Per-entry overrides for multiple entries |
-
-**Example:**
-
-```ts
-i18nPlugin({
-  localeDetection: {
-    localePathRedirect: true,
-    i18nextDetector: true,
-    languages: ['zh', 'en', 'ja'],
-    fallbackLanguage: 'en',
-    detection: {
-      order: ['path', 'cookie', 'header'],
-      lookupCookie: 'i18next',
-      caches: ['cookie'],
-    },
-  },
-});
-```
-
-### backend Options
-
-```ts
-interface BackendOptions {
-  // Whether to enable backend resource loading.
-  // Automatically enabled when loadPath/addPath is configured, or when a locales directory exists.
-  enabled?: boolean;
-
-  // Decides which URL or local file to request for translations. Supports {{lng}} and {{ns}}.
-  // Default: '/locales/{{lng}}/{{ns}}.json'
-  loadPath?: string;
-
-  // Path for reporting missing translations (optional).
-  addPath?: string;
-
-  // Enables the custom backend SDK. The actual loader is provided in runtime config.
-  sdk?: boolean | string;
-
-  // Cache strategy for chained backend mode, effective when both loadPath and sdk are configured.
-  // 'none'                  - use local files and do not request the custom backend after a hit
-  // 'refresh'               - continue requesting the custom backend and update cache, but not the page
-  // 'refreshAndUpdateStore' - continue requesting and update page text as well (default)
-  cacheHitMode?: 'none' | 'refresh' | 'refreshAndUpdateStore';
-
-  // Per-entry overrides for multiple-entry scenarios.
-  backendOptionsByEntry?: Record<string, BaseBackendOptions>;
-}
-```
-
-**About the `sdk` field:** In `modern.config.ts`, set it to `true` to declare that the SDK backend is enabled. Provide the actual loader in `initOptions.backend.sdk` in `modern.runtime.ts`. See [Resource Loading -> Custom Backend](./resource-loading.md#custom-backend).
-
-**backend auto-enable rules:**
-
-| Situation | Result |
-| --- | --- |
-| `loadPath` or `addPath` is configured | Automatically enabled. No need to write `enabled: true` |
-| No backend is configured, but a `locales` directory exists and contains JSON files | Automatically enabled with the default `loadPath` |
-| `enabled: false` is set explicitly | Disabled, and auto-detection is skipped |
-
-Auto-detected directory locations, in priority order:
-
-1. `{project root}/config/public/locales`
-2. The `locales` subdirectory under the directory configured by `server.publicDir`
-
-**Which backend should you choose?**
-
-| Scenario | Recommended approach |
-| --- | --- |
-| Translation files are local to the project | Static file backend (configure `loadPath`; CSR/SSR switch automatically) |
-| Translations come from a remote API or translation platform | Custom backend (configure `sdk: true`) |
-| Local fallback + remote real-time updates | Chained backend (configure both `loadPath` and `sdk`) |
-
-See [Resource Loading](./resource-loading.md) for detailed usage.
-
-## Runtime Configuration
-
-```ts title="src/modern.runtime.ts"
-import { defineRuntimeConfig } from '@modern-js/runtime';
-import i18next from 'i18next';
-
-const i18nInstance = i18next.createInstance();
-
-export default defineRuntimeConfig({
-  i18n: {
-    i18nInstance,   // Optional. An isolated instance is recommended.
-    initOptions: {
-      fallbackLng: 'en',
-      supportedLngs: ['zh', 'en'],
-      ns: ['translation'],
-      defaultNS: 'translation',
-      interpolation: {
-        escapeValue: false, // React already escapes text; disable this to avoid double escaping.
-      },
-    },
-  },
-});
-```
-
-### i18nInstance Configuration
-
-If you need to use a custom i18n instance, provide it in the runtime configuration:
-
-import CustomInstanceCode from '@site-docs/components/international/custom-instance-code';
-
-<CustomInstanceCode />
-
-### initOptions
-
-import Desc from '@site-docs/components/international/init-options-desc';
-
-<Desc />
-
-| Field | Description |
-| --- | --- |
-| `fallbackLng` | Which language resources i18next falls back to when a translation key is missing. Supports strings, arrays, and maps (fallback chains) |
-| `supportedLngs` | Language list supported by i18next |
-| `ns` | Namespace list. Default is `['translation']` |
-| `defaultNS` | Default namespace. Default is `'translation'` |
-| `lng` | Forces the initial language. Usually not needed because the detector decides it |
-
-`fallbackLng` supports fallback chains, which are useful for regional language degradation:
-
-```ts
-initOptions: {
-  lng: 'zh-CN',
-  fallbackLng: {
-    'zh-CN': ['zh', 'en'], // If zh-CN is missing, try zh first, then en.
-    default: ['en'],
-  },
-},
-```
-
-### Custom Backend Function Configuration
-
-The actual loader function for a custom backend must be provided in runtime configuration:
-
-```ts
-// modern.config.ts: only declare that it is enabled.
-i18nPlugin({
-  backend: { sdk: true },
-});
-
-// modern.runtime.ts: provide the actual function.
-import type { I18nSdkLoader } from '@modern-js/plugin-i18n/runtime';
-
-const myLoader: I18nSdkLoader = async options => {
-  if (options.lng && options.ns) {
-    const res = await fetch(`/api/i18n/${options.lng}/${options.ns}`);
-    return res.json();
-  }
-  return {};
-};
-
-export default defineRuntimeConfig({
-  i18n: {
-    initOptions: {
-      backend: { sdk: myLoader },
-    },
-  },
-});
-```
-
-For complete usage, see [Resource Loading -> Custom Backend](./resource-loading.md#custom-backend).
-
-## Multiple Entries
-
-Multiple-entry projects can override configuration per entry. See [Advanced Usage -> Multiple Entries](./advanced.md#multiple-entries).

package/docs/guides/advanced-features/international.mdx

@@ -1,29 +0,0 @@
----
-title: Internationalization
----
-
-# Internationalization
-
-import I18nPluginIntroduce from '@site-docs/components/international/introduce';
-
-<I18nPluginIntroduce />
-
-## Where to start?
-
-| What you want to do | Documentation |
-| --- | --- |
-| Integrate for the first time and run an example | [Quick Start](./international/quick-start.md) |
-| Learn all configuration options | [Configuration](./international/configuration.md) |
-| Detect language from URL / Cookie / Header | [Locale Detection](./international/locale-detection.md) |
-| Implement paths with locale prefixes, such as `/en/about` | [Routing Integration](./international/routing.md) |
-| Load translation resources from a remote service or platform | [Resource Loading -> Custom Backend](./international/resource-loading.md#custom-backend) |
-| SSR, multiple entries, or custom instances | [Advanced Usage](./international/advanced.md) |
-| Look up Hooks / components / type definitions | [API Reference](./international/api.md) |
-
-## Core Capabilities
-
-- **Locale detection**: Supports detection from URL path, Cookie, LocalStorage, request headers, browser settings, and other sources, with configurable priority.
-- **Resource loading**: Supports HTTP static files, file system loading for SSR, custom SDK functions, and chained backend progressive loading.
-- **Routing integration**: Automatically adds locale path prefixes such as `/en/about`, and provides the `I18nLink` component for locale-aware navigation.
-- **SSR support**: Detects the language on the server and injects it into the page so the client can reuse it directly and avoid language flicker.
-- **TypeScript support**: Provides complete type definitions and supports type-safe translation keys.

package/docs/guides/advanced-features/page-performance/_meta.json

@@ -1 +0,0 @@
-["code-split", "inline-assets", "optimize-bundle", "react-compiler"]

package/docs/guides/advanced-features/server-monitor/_meta.json

@@ -1 +0,0 @@
-["monitors", "logger", "metrics"]

package/docs/guides/advanced-features/server-monitor/logger.mdx

@@ -1,19 +0,0 @@
-# Logs Events
-
-Log events are distributed by Modern.js as events of type `log`.
-
-## Built-in Events
-
-Based on server-side runtime logic, Modern.js provides the following log events:
-
-| Stage           | Message                                      | Level |
-| --------------- | -------------------------------------------- | ----- |
-| RENDER_HTML     | App Render To HTML                           | error |
-| RENDER_STREAM   | An error occurs during streaming SSR         | error |
-| RENDER_SHELL    | An error occurs during streaming render shell | error |
-
-## Built-in Monitor
-
-import InternalLogger from '@site-docs-en/components/internal-logger.mdx';
-
-<InternalLogger />

package/docs/guides/advanced-features/server-monitor/metrics.mdx

@@ -1,41 +0,0 @@
-# Metrics Events
-
-Metric events are distributed by Monitors as events of type `timing` or `counter`.
-
-## Built-in Events
-
-When SSR is enabled, we need to monitor server-side phase durations and have the capability to diagnose server-side issues.
-
-Based on server-side runtime logic, Modern.js provides the following metric events:
-
-| Key                      | Description              |
-| ------------------------ | ------------------------ |
-| server-handle-request    | Modern.js Server request handling duration                          |
-| ssr-render-shell         | [SSR] When using Streaming SSR, React renders a shell for early streaming. This marks shell rendering completion time |
-| ssr-render-html          | [SSR] Time taken by React to render component tree to HTML (typically under 50ms) |
-| server-middleware        | Total execution time of Modern.js custom server middlewares         |
-| server-loader            | Server-side Data Loader total duration                          |
-| server-loader-#id        | Individual Data Loader durations on server-side                 |
-| server-loader-navigation | Server-side Data Loader duration during client navigation       |
-
-Modern.js server workflow diagram:
-
-![server](https://lf3-static.bytednsdoc.com/obj/eden-cn/eeeh7uhbepxlpe/edenx-website/e374def0-c179-40aa-9cfe-e82e181663b1.jpeg)
-
-## Built-in Monitor
-
-import InternalMetrics from '@site-docs-en/components/internal-metrics.mdx';
-
-<InternalMetrics />
-
-## Server-Timing
-
-Modern.js injects phase metrics as Server-Timing headers into HTML responses.
-
-Developers can retrieve these metrics using the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance) in browsers:
-
-```ts
-const navigation = performance.getEntriesByType('navigation')[0];
-const serverTiming = navigation.serverTiming;
-console.log(serverTiming);
-```

package/docs/guides/basic-features/_meta.json

@@ -1,49 +0,0 @@
-[
-  {
-    "type": "dir",
-    "name": "routes",
-    "label": "Routes",
-    "collapsed": true
-  },
-  {
-    "type": "dir",
-    "name": "data",
-    "label": "data-solution",
-    "collapsed": true
-  },
-  {
-    "type": "dir",
-    "name": "render",
-    "label": "rendering",
-    "collapsed": true
-  },
-  {
-    "type": "dir",
-    "name": "css",
-    "label": "css-solution",
-    "collapsed": true
-  },
-  "html",
-  {
-    "type": "dir",
-    "name": "static-assets",
-    "label": "static-assets",
-    "collapsed": true
-  },
-  {
-    "type": "dir",
-    "name": "debug",
-    "label": "debug",
-    "collapsed": true
-  },
-  {
-    "type": "dir",
-    "name": "testing",
-    "label": "testing",
-    "collapsed": true
-  },
-  "alias",
-  "env-vars",
-  "output-files",
-  "deploy"
-]

package/docs/guides/basic-features/css/_meta.json

@@ -1 +0,0 @@
-["css", "css-modules", "css-in-js", "tailwindcss"]

package/docs/guides/basic-features/data/_meta.json

@@ -1 +0,0 @@
-["data-fetch", "data-write", "data-cache"]

package/docs/guides/basic-features/debug/_meta.json

@@ -1 +0,0 @@
-["mock", "proxy", "rsdoctor", "using-storybook"]

package/docs/guides/basic-features/render/_meta.json

@@ -1 +0,0 @@
-["overview", "ssr", "streaming-ssr", "ssr-cache", "ssg", "rsc", "before-render"]

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

@@ -1,51 +0,0 @@
----
-title: Rendering Mode Overview
----
-
-# Rendering Mode Overview
-
-Modern.js supports multiple rendering modes, and different rendering modes are suitable for different scenarios. Choosing the right rendering mode can significantly improve application performance and user experience.
-
-## 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 |
-
-## 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 | - |
-
-## How to Choose
-
-### Quick Decision Guide
-
-- **Static Content + SEO Required** → **SSG**
-- **SEO Required + First Screen Performance** → **Streaming SSR** (default)
-- **Pursuing Optimal Performance** → **Streaming SSR + RSC**
-- **CSR Project Gradual Optimization** → **CSR + RSC**
-- **Highly Interactive + No SEO Needed** → **CSR**
-
-### Combining Modes
-
-Modern.js supports combining multiple rendering modes:
-
-- **Streaming SSR + RSC**: Streaming rendering + reduced client-side code
-- **SSG + SSR**: Some pages static, some pages dynamic
-- **CSR + RSC**: Client-side rendering + partial Server Components
-
-## Related Documentation
-
-- [Server-Side Rendering (SSR)](/guides/basic-features/render/ssr)
-- [Streaming Server-Side Rendering (Streaming SSR)](/guides/basic-features/render/streaming-ssr)
-- [React Server Components (RSC)](/guides/basic-features/render/rsc)
-- [Static Site Generation (SSG)](/guides/basic-features/render/ssg)
-- [Rendering Cache](/guides/basic-features/render/ssr-cache)

package/docs/guides/basic-features/routes/_meta.json

@@ -1 +0,0 @@
-["routes", "config-routes"]

package/docs/guides/basic-features/static-assets/_meta.json

@@ -1 +0,0 @@
-["json-files", "svg-assets", "wasm-assets"]

package/docs/guides/basic-features/testing/_meta.json

@@ -1 +0,0 @@
-["rstest", "playwright"]

package/docs/guides/concept/_meta.json

@@ -1 +0,0 @@
-["entries", "builder", "server"]

package/docs/guides/get-started/_meta.json

@@ -1,9 +0,0 @@
-[
-  "ultramodern",
-  "introduction",
-  "quick-start",
-  "upgrade",
-  "glossary",
-  "tech-stack",
-  "ai-coding-agents"
-]

package/docs/guides/get-started/glossary.mdx

@@ -1,63 +0,0 @@
----
-sidebar_position: 4
----
-
-# Glossary
-
-## BFF
-
-BFF is short for "Backend For Frontend". It is an architecture pattern that involves creating a backend service for frontend applications.
-
-The BFF service acts as an intermediary between the frontend application and the server API, and can provide customized APIs for the frontend to use. This allows frontend developers to have more control over the data and functionality they need, without relying on the backend service to provide the corresponding capabilities.
-
-## Bundler
-
-import Bundler from '@site-docs-en/components/bundler.mdx';
-
-<Bundler />
-
-## CSR
-
-CSR stands for "Client-Side Rendering". It means that the page is rendered in the browser using JavaScript, and logic such as data fetching, templates, and routing is completed on the client side rather than the server.
-
-In CSR, the server sends an empty HTML shell and some JavaScript scripts to the browser, and the browser fetching data from the server's API and renders dynamic content to the page.
-
-## Module Federation
-
-import ModuleFederation from '@site-docs-en/components/module-federation.mdx';
-
-<ModuleFederation />
-
-## Rsbuild
-
-import Rsbuild from '@site-docs-en/components/rsbuild.mdx';
-
-<Rsbuild />
-
-## Rspack
-
-import Rspack from '@site-docs-en/components/rspack.mdx';
-
-<Rspack />
-
-## SSR
-
-SSR stands for "Server-Side Rendering". It means that the HTML of the web page is generated by the server and sent to the client, rather than sending only an empty HTML shell and relying on JavaScript to generate the page content.
-
-In traditional client-side rendering, the server sends an empty HTML shell and some JavaScript scripts to the client, and then fetching data from the server's API and fills the page with dynamic content. This leads to slow initial page loading times and is not conducive to user experience and SEO.
-
-With SSR, the server generates HTML that already contains dynamic content and sends it to the client. This makes the initial page loading faster and more SEO-friendly, as search engines can crawl the rendered page.
-
-## SSG
-
-SSG stands for "Static Site Generation". It means that web pages are pre-rendered as static HTML and served directly to the client, without the need for the server to generate HTML in real-time.
-
-In traditional SSR, the server generates HTML in real-time every time a user requests a page. With SSG, HTML can be generated in advance during the build process and hosted on a CDN or other static assets service.
-
-Compared to traditional SSR, SSG can provide faster loading speeds and less server-side overhead, as there is no need to maintain a server to generate HTML in real-time. However, SSG is not suitable for websites that require dynamic content, as the HTML is generated during the build process and does not support real-time updates.
-
-## SWC
-
-import SWC from '@site-docs-en/components/swc.mdx';
-
-<SWC />