> ## 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 Roadmap: What's Shipped and What's Next

> Honest status of knitkit packages: what shipped in v0.1, what's coming next, what's planned for later, and what the project will not build.

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.

<Note>
  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](https://github.com/minipekka25/knitkit) to be notified of releases.
</Note>

***

## Shipped

Everything listed here is done and available in the `0.1.x` packages.

<Accordion title="@knitkit/runtime — browser core">
  `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.
</Accordion>

<Accordion title="Manifest spec v0.1">
  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.
</Accordion>

<Accordion title="@knitkit/cli — build tooling">
  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).
</Accordion>

<Accordion title="@knitkit/node — Node SSR">
  `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.
</Accordion>

<Accordion title="@knitkit/react — React integration">
  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.
</Accordion>

<Accordion title="@knitkit/overrides — local-override dev tool">
  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.
</Accordion>

<Accordion title="@knitkit/edge — edge composition">
  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.
</Accordion>

<Accordion title="Tier-2 fragment composition">
  `@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.
</Accordion>

<Accordion title="Examples and docs site">
  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.
</Accordion>

<Accordion title="Release discipline">
  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.
</Accordion>

***

## 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.