Examples

The library repo ships three example apps under examples/. They are the reference implementations these docs quote — and the set every feature is verified against before release.

All three are built and served as static files on this site, so you can drive the real thing here:

The shell fetches mfes.json, validates every entry, gates them on version and inter-plugin dependencies, then mounts one <InitRemote> per survivor. Everything in the sidebar, the toolbar and the settings page arrived from a registry at runtime — the host imported none of it at build time.

Six manifest entries, and four of them fail on purpose so the guardrails are visible rather than claimed:

Things worth clicking:

import { useRegistryItem } from "@z0devs/mf-plugin-kit";
 
const widget = useRegistryItem(registries.components, "basic_plugin:SalesWidget");
return widget ? <widget.component /> : <Fallback />;

basic-shell — the host#

An Rspack host that wires the whole stack in four small files.

examples/basic-shell/
├── rspack.config.ts          # exposes ./sharedStore, shares react/react-dom/react-router-dom
├── public/mfes.json          # the manifest — six entries: two that load, four that fail on purpose
└── src/
    ├── main.tsx              # MF runtime init + provider stack
    ├── routes.tsx            # PluginRouteLoader inside the dynamic route tree
    ├── auth/fakeAuth.ts      # stub auth adapter
    └── store/
        ├── sharedStore.tsx   # defineSharedStore + a demo onboarding step
        └── useSharedStore.ts # back-compat flat expose

What it demonstrates:

• defineSharedStore with values, four registries, features: { onboarding: true, router: true } and a typed events emitter
• export default sharedStore.useShellSharedStore — the expose contract the plugin bridge expects
• A render-action onboarding step registered by the shell itself
• PluginRouteLoader mounted as a route element, with initialRoutes shaped so dynamic routes land in the right place
• dts.generateTypes so plugins can type shell/sharedStore against the real store

pnpm --filter @z0devs/basic-shell dev      # http://localhost:3400

basic-plugin — the remote#

An Rspack remote that runs federated and standalone.

examples/basic-plugin/
├── rspack.config.ts          # exposes ./init + ./HomePage, DefinePlugin for IS_STANDALONE, dts on
├── manifest-entry.json       # what the host appends to mfes.json
├── public/env-config.js      # runtime env injection demo
└── src/
    ├── init.tsx              # registers a route + nav item through namespaced registries
    ├── HomePage.tsx          # reads the host store
    ├── main.tsx              # standalone entry
    └── core/
        ├── LocalContext.ts   # createLocalStubContext — fail-loud
        └── useShared.tsx     # createPluginStoreBridge + top-level `await bridge.ready`

What it demonstrates:

• The self-initializing bridge: await bridge.ready at module scope, so no provider, HOC or Suspense is needed anywhere
• Registering routes and nav through props.registries with short local ids
• Cleanup on unmount, so host re-inits don't accumulate stale contributions
• Standalone mode via IS_STANDALONE=true, with a stub that throws on unstubbed reads
• Cross-remote type emission (dist/@mf-types)

pnpm --filter @z0devs/basic-plugin dev              # federated, port 3401
pnpm --filter @z0devs/basic-plugin dev:standalone   # no host required

vite-plugin — the cross-bundler case#

A Vite-built remote (@module-federation/vite) mounted inside the Rspack host, sharing the host's React and reading the host's store through the top-level-await bridge. Its mfes.json entry ships enabled: true: both remotes reach ready on a cold boot.

pnpm --filter @z0devs/vite-plugin-example build
pnpm --filter @z0devs/vite-plugin-example preview        # 3402 — must be preview, not dev
pnpm --filter @z0devs/basic-shell dev                    # 3400
pnpm --filter @z0devs/basic-plugin dev                   # 3401

http://localhost:3400 then shows a Vite Plugin nav item, and /vite-plugin renders the remote with the host's user and Mode: federated.

What it demonstrates:

• Symmetric share sets including the subpath entrypoints (react/jsx-runtime, react/jsx-dev-runtime, react-dom/client) — the root cause of duplicate React in this setup
• import: false on the remote's shares, conditional on federated mode
• A var container (varFilename) registered by the host with type: "global", because an ESM container self-initializes its share scope before the host can hand over its own
• Serving the built output — the Vite dev server injects a Node-only module into the entry

The full reasoning for each, with the failure mode you get without it, is in cross-bundler settings.

Running host + plugin together#

pnpm install
pnpm build          # builds the packages the examples consume

pnpm --filter @z0devs/basic-plugin dev

pnpm --filter @z0devs/basic-shell dev

Using them as a starting point#

The plugin example is the same source create-z0-plugin ships as its template — so pnpm create z0-plugin my-plugin gets you basic-plugin with your ports and metadata already substituted. For the host, copy basic-shell's four files and replace fakeAuth with your real auth adapter and the demo values with your own.

Next#