Advanced: No Manifest Host

A No Manifest Host loads one known module directly — a hand-rolled import map entry, or a direct URL import — instead of adopting a manifest and resolving routes against it. There’s no defineManifest(), no resolveRoute(), no createImportMap(). The host just names, once, where the one module it cares about lives.

This page is the honest accounting of what that buys you, and what it doesn’t.

What works today

Module Boundary — either export style, Direct or Injected — works with no manifest involved. Decoupling a Slice from an Existing App is the complete worked example: a host with a hardcoded <script type="importmap"> entry pointing one specifier at one URL, and a boundary wrapper (createInjectedModuleBoundary in that guide, but createDynamicModuleBoundary for Direct works the same way) that imports it. No manifest object exists anywhere in that host’s code, and the mechanism isn’t reduced or unsupported — it’s the same createDynamicModuleBoundary/createInjectedModuleBoundary factories a Manifest Host uses, pointed at a specifier the host wrote by hand instead of one a manifest generated.

That said, a Manifest Host is still the recommended default even for Module Boundary — reach for No Manifest Host deliberately, not as the usual starting point. A hand-rolled import map entry is one specifier the host maintains by hand forever; a manifest’s resolveRoute() is what lets that mapping scale to more than one slice without the host hand-editing a growing list of specifier-to-URL pairs on every new route. One slice, wired in once, is the situation this page’s worked example covers well. More than that, and the manifest earns its keep.

The gap: No Manifest Host + Independent Mount isn’t implemented

Independent Mount has no No Manifest Host path. createRuntimeHost()’s options type is:

export type RuntimeHostOptions = {
  manifest: RuntimeCompositionManifest;
  target: Element;
  onLoading?: (path: string) => void;
  onReady?: (path: string) => void;
  onError?: (error: unknown, path: string) => void;
  importer?: DynamicImporter;
};

manifest is required, typed as a full RuntimeCompositionManifest — not optional, not a narrower single-slice shape. There’s no manifest-free constructor, and no lower-level primitive that gets you mount/unmount lifecycle management (stale-navigation discarding, onLoading/onReady/onError) without one. createRuntimeHostObservable() takes the same required manifest field, so the adapters built on it — createReactAdapter(), createVueAdapter() — inherit the same requirement.

The workaround: adopt a Manifest Host with a manifest that routes exactly one slice. A one-entry externalDeps list and a single namespace segment is a complete, valid RuntimeCompositionManifest — nothing requires a manifest to describe more than one slice. See Quick Start: Independent Mount for the full setup; the manifest it walks through scales down to one slice without any change in shape.

The other gap: Module Boundary — Direct has no Vue equivalent

Independent of the manifest question: Module Boundary — Direct (createDynamicModuleBoundary) is React-only. There is no @rmc-toolkit/vue function that takes a plain default-exported Vue component the way createDynamicModuleBoundary takes a plain default-exported React component. This holds with or without a manifest — it’s a gap in the Direct convention itself, not something No Manifest Host specifically triggers.

The workaround: Module Boundary — Injected (createInjectedModuleBoundary) supports both React and Vue, with or without a manifest. A Vue slice that needs to render inside a host’s own component tree uses Injected’s default-exported-factory convention instead of Direct’s default-exported-component convention.

These are gaps, not a roadmap

Nothing above is “coming soon.” No Manifest Host + Independent Mount and Module Boundary Direct for Vue are both things the toolkit doesn’t do today, with no committed timeline to add either. The workarounds above — a one-slice manifest, or Injected instead of Direct — aren’t stopgaps pending a future release; they’re the actual, complete way to get the equivalent result with what exists right now.