Skip to main content
knitkit is pre-1.0, published under the @knitkit/* npm scope, and this page reflects honest current status — not aspirational marketing. The goal is to give you an accurate picture of what you can rely on today, what is actively being worked on, and where the project’s boundaries are. If you are evaluating knitkit for a production project, read this page before committing.
Pre-1.0 APIs may change before the 1.0 release. If you adopt knitkit now, pin your @knitkit/* dependencies to an exact version and review the changelog when upgrading. Star the GitHub repository to be notified of releases.

​
Shipped

Everything listed here is done and available in the 0.1.x packages.
registerRemotes, loadRemote, in-house semver negotiation (caret/tilde/x-ranges/comparators), import-map injection, manifest validation, coded FedkitError instances with machine-readable code and optional suggestion properties, and augmentable RemoteModules typing for loadRemote. Under 5 KB brotli. Zero dependencies.
A versioned manifest specification lives in /spec/manifest-0.1.md in the repository. The spec is versioned from day one so tooling can detect incompatible manifests and throw KNIT_ERR_MANIFEST_INVALID with a clear message. Third-party tools can implement the spec independently.
Shared-deps emitter (esbuild-based), manifest generation, sha384 SRI hash computation for all emitted assets, knitkit types generate (emits .d.ts files alongside the manifest), and knitkit types sync (fetches remote .d.ts files and generates the knitkit-remotes.d.ts host declaration).
module.register loader hooks for Node.js, SRI verification before any remote code executes, a module cache that prevents redundant fetches within a request, and hydration-parity import-map serialization so the server’s negotiated import map can be embedded in the HTML shell for the browser to reuse.
A "use client"-annotated <RemoteComponent> that wraps loadRemote with lazy loading, React.Suspense, and an error boundary. Drop it into any React or Next.js host without writing your own async boundary.
A developer tool that lets you point a single remote at a local dev server (localhost) while all other remotes continue to run from their deployed URLs. Overrides persist in localStorage and surface through a small UI widget injected into the page.
ESI-style HTML fragment stream-stitching and import-map injection for Cloudflare Workers, Deno Deploy, and Vercel Edge. Built on Web-standard fetch and Web Streams — no Node.js APIs, no bundler plugins.
@knitkit/react’s <RemoteFragment> (client boundary) and the edge-composition example demonstrate independent apps stitched at the edge — each fragment its own framework, no shared React required. Complements @knitkit/edge’s stream-stitching with a React-side integration point.
Four runnable examples, each with a self-booting Playwright smoke test: react-host-vue-remote (React host + Vue 3 remote, shared state proven identical across the framework boundary), react-host-react-remote (<RemoteComponent> with shared React hooks), node-ssr (Node SSR of a federated React component with SRI verification), and edge-composition (two independent apps stitched at the edge). The documentation site is published with Mintlify.
Changesets configured for changelog generation and coordinated version bumps across the monorepo. 0.1.0 is pending the public GitHub repo and npm scope publish.

​
Next

These items are actively being worked on or are the immediate next priority. Next.js App Router story — this needs an honest resolution before being called done. A true shared-React <RemoteComponent> inside Next.js App Router is not zero-config: Next bundles its own React, so a federated remote’s import "react" resolves to a CDN React via the import map, producing two React instances and the “invalid hook call” error. Sharing React with Next requires a next.config.js externals change. An isolated, hooks-free remote widget can be embedded zero-config today. The shared-React case is the open item, and the goal is a documented, tested approach — not a workaround.

​
Later

These items are on the roadmap but not the immediate priority.
  • Runtime SRI enforcement for exposed modules in the browser. The browser platform does not currently expose a hook to verify SRI before import() resolves; this is a platform limitation. The approach being evaluated is manifest signing as a complementary mechanism.
  • Manifest signing. Cryptographic signing of the manifest so hosts can verify authenticity in addition to per-asset integrity.
  • Benchmark harness. A reproducible cold-load and bytes-shipped benchmark comparing knitkit against Module Federation 2.0, with results committed to the repository and re-run in CI.
  • --auto shared-list proposer. A CLI flag that analyses your package.json and the remote manifests your host consumes to suggest a shared list — if there is demand for it.
  • Tier-3 watch item: module-level RSC/Flight federation. No standard exists yet for cross-app React Server Component Flight module references. The project is monitoring react-server-dom-esm and will revisit when the platform matures.

​
Won’t build

knitkit is deliberately scoped. The following are not on the roadmap — not eventually, not with enough votes:
  • Cross-remote HMR. Live module replacement across a remote/host boundary requires bundler coupling, which knitkit refuses by design. Use the @knitkit/overrides widget to point a remote at localhost during development.
  • Module-level RSC/Flight federation. No cross-app Flight module reference standard exists. knitkit is RSC-compatible (you can load RSC-rendered HTML fragments at the edge) but will not attempt RSC-federation until the platform defines it.
  • React Native. Out of scope — no import maps, no native ESM in the React Native runtime.
  • Maintained Webpack, Rspack, or Vite plugins. knitkit is runtime-first and bundler-agnostic. If you want a Webpack plugin, use Module Federation.
  • Automatic transitive sharing. The shared surface is explicit by design. You declare every shared package; nothing is shared silently. This is where Module Federation’s worst bugs live — knitkit treats mandatory explicitness as a permanent architectural choice.
  • Patching framework internals. knitkit will not monkey-patch React, Vue, or any other framework to make federation work. If federation requires a framework patch, the approach is wrong.