扩展前端接入

扩展前端由后端生成的 catalog 与应用维护的 binding 组成。catalog 决定安装集合和贡献元数据，binding 将贡献连接到实现。

注册惰性 binding

模板的 src/extensions/bindings.ts 使用如下结构：

import type { ExtensionBinding } from '@modu/web/extensions';

export const extensionBindings = [{
  owner: 'app.module/receipt',
  kind: 'page',
  id: 'receipts',
  version: '1.0.0',
  loader: () => import('./implementations/app_module__receipt/Page'),
  locales: {
    'zh-CN': () => import('./implementations/app_module__receipt/zh-CN'),
    'en-US': () => import('./implementations/app_module__receipt/en-US'),
  },
}] as const satisfies readonly ExtensionBinding[];

示例对应模板中已有的回执实现文件。新增扩展时使用自己的 owner、贡献 id、合同版本和文件路径。

路径、权限、标题 key 与 bundle budget 从 Manifest 派生，binding 不手写另一份。动态 import 使用字面量路径，便于构建工具识别独立 chunk。

语言资源

扩展内部文案通过 @modu/web/extensions 的 useExtensionMessages() 读取当前扩展语言包。每个 binding 提供 zh-CN 与 en-US 加载入口，并覆盖 Manifest 引用的标题 key。

业务页面的全局语言资源和扩展作用域语言资源各自维护。不依赖另一个扩展的内部资源或实现目录。

接入运行时

将 catalog 传给 createRoutes，并将 catalog 与 extensionBindings 一起传给 createRuntime。完整示例见前端业务开发。

后端装配变化后，从应用 server 重新运行 go run ./cmd/modu catalog generate，再验证前端。

检查真实构建

# 应用 web/
pnpm extension:check
pnpm typecheck
pnpm build
pnpm extension:verify-build

extension:check 检查安装包、catalog、binding、语言 key 与导入边界。extension:verify-build 使用实际构建产物检查惰性 chunk 和体积预算。

只声明 lazy loader 还不够；实现被其他入口提前导入时，仍可能进入首屏包。实际构建检查用于发现这类问题。