> ## Documentation Index
> Fetch the complete documentation index at: https://knitkit.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# knitkit: Runtime-First Module Federation Without Bundlers

> Learn what knitkit is, how native import maps eliminate the bundler share-scope footgun, and which packages to install for your project.

knitkit is a runtime-first module federation system built on native ES modules and import maps. Where traditional federation tools require a bundler plugin sitting between you and your output, knitkit ships a tiny (\< 5 KB) runtime, a versioned manifest format, and a small CLI — and that's the complete stack. You declare which modules a remote exposes and which dependencies it shares, run `knitkit build`, and any host on any platform can load that remote at runtime without touching its own build config.

<Note>
  knitkit is pre-1.0, published under the `@knitkit/*` npm scope. APIs may change before the 1.0 release.
</Note>

## The problem with bundler-coupled federation

Every major federation solution today — `ModuleFederationPlugin`, `vite-plugin-federation`, and their successors — asks you to couple your build output to a plugin's behaviour. That coupling creates three persistent problems.

**The singleton footgun.** Shared dependencies like React are coordinated through a "share scope": a runtime registry that negotiates which version wins. When configuration drifts between host and remote, or when a version range is too loose, two copies of React load silently. The result is the infamous "Invalid hook call" error, which has generated thousands of Stack Overflow questions and remains the ecosystem's most common federation bug.

**The plugin treadmill.** When your bundler releases a major version, you wait for the federation plugin to catch up. When the plugin releases a major version, you audit a new config surface. Both sides of the equation are moving targets, and SSR support is consistently labeled experimental even by the plugins' own authors.

**The SSR wall.** Because share-scope negotiation and chunk-loading machinery are wired deeply into bundler output format, making the same remote work server-side typically means a separate configuration path, separate loaders, and separate testing surface.

## How knitkit works

knitkit replaces the entire share-scope machinery with a web platform primitive: **import maps**.

When you call `registerRemotes`, knitkit fetches each remote's `knit.manifest.json`, runs version negotiation across all declared shared dependencies, and injects a single import map into the page before any module import resolves through it. From that point forward, every `import "react"` — whether from the host's own code, a React remote, or a Vue remote — resolves to the same URL and therefore the same module instance in the browser's module cache.

There is no share scope, no runtime registry, and no way to accidentally load React twice. The import map is inspectable in DevTools: open the `<script type="importmap">` entry and you can read exactly which version won and from which URL. knitkit calls this **debuggability by construction**.

On the server, Node's `module.register` loader hooks intercept the same import specifiers using the same negotiated map. On the edge, `@knitkit/edge` injects the map into a streamed HTML response. One manifest, one negotiation algorithm, three substrates.

## Packages

knitkit is a monorepo. Install only the packages your use case requires.

| Package              | Purpose                                                                                                                                       |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `@knitkit/runtime`   | Browser core: `registerRemotes`, `loadRemote`, import-map negotiation and injection. \< 5 KB, zero dependencies.                              |
| `@knitkit/cli`       | Build-time tooling: bundles shared ESM assets from `node_modules` (via esbuild), generates `knit.manifest.json`, and computes SRI hashes.     |
| `@knitkit/node`      | Node SSR support via `module.register` loader hooks, SRI verification, module cache, and hydration-parity import-map serialization into HTML. |
| `@knitkit/react`     | Thin `"use client"` `<RemoteComponent>` wrapper providing lazy loading, Suspense, and a built-in error boundary over `loadRemote`.            |
| `@knitkit/overrides` | Local-override development widget: redirect a deployed remote to `localhost` using `localStorage`, without rebuilding the host.               |
| `@knitkit/edge`      | ESI-style HTML fragment stream-stitching and import-map injection for Cloudflare Workers, Deno Deploy, and Vercel Edge.                       |

<Tip>
  For most browser projects, you only need `@knitkit/runtime` (runtime dependency) and `@knitkit/cli` (dev dependency). Add the other packages as your architecture grows.
</Tip>

## Browser support

Import maps are supported in Chrome 89+, Firefox 108+, and Safari 16.4+. The `integrity` key for module-level SRI requires Chrome 127+, Firefox 138+, and Safari 18.4+. If you need to support older browsers, `es-module-shims` is a documented polyfill path, but it is never the default — knitkit is built for the modern platform baseline.

<Warning>
  Browser support figures change as new versions ship. Verify current data at [caniuse.com/import-maps](https://caniuse.com/import-maps) before committing to a support matrix.
</Warning>