Compose web apps built on different stacks into one product at run time, over a typed, secured channel.
Docs · Get started · How it works · Demos · Packages · Manifesto
Your React app, the Angular one next door, and that jQuery thing from 2014 can share a page without sharing a build. Each stays its own deployment at its own origin. The host installs one shell package and talks to it over a typed contract, sealed with per-session keys when the payload matters. That is @hyperfrontend/features: the SDK, the hf CLI and the dev server.
The architecture guide walks the seam in depth: the handshake, the four-state liveness watchdog, and the polite teardown. The security model says what the sealed envelope is worth against which adversary, and which controls stay yours.
Eight koi, eight frameworks, eight separately deployed apps, one pond. The gallery also runs Clock, a Vue timepiece in a React host across a cross-site boundary, and Heartbeat, liveness and latency, and what a host should do when a feature stops answering.
npm install @hyperfrontend/featuresA feature declares what it sends and accepts; a host mounts it and gets a typed handle back:
// In the feature app, from '@hyperfrontend/features/hostee'
const feature = createFeature({ name: 'checkout', contract })
await feature.ready()
feature.send('order-placed', { id: 'A-1094' })
// In the host app, from '@hyperfrontend/features/host'
const checkout = createShell({ modes: { dialog: mountDialog }, url: 'https://checkout.example.com' })
checkout.on('order-placed', (order) => showReceipt(order))
checkout.open({ displayMode: DisplayMode.Dialog })The bundled hf CLI turns an existing app into a feature and packs the shell a host installs:
# scaffold the feature side into an existing app
npx @hyperfrontend/features init
# bundle a self-contained shell package, with the security envelope baked in
npx @hyperfrontend/features build --protocol v4
# serve both sides locally, with a debug UI for the traffic between them
npx @hyperfrontend/features devStart with Core Concepts, then the guides and tutorials, each one verified against code that runs. Every option, handle and payload type is in the API reference. Not sure the pattern fits your case? Take the fit assessment.
Every package is published on its own and documented on the libraries index, the flagship first and the single-purpose utilities last. The ones under the flagship exist because it needed them, and each one solves a problem an application has whether or not it is a micro-frontend.
All nineteen packages
| npm | What it does |
|---|---|
| @hyperfrontend/features | The SDK, CLI and dev server: embed another team's app over a typed, supervised channel · docs |
| @hyperfrontend/nexus | Contract-validated messaging between windows, frames and workers, over a real handshake · docs |
| @hyperfrontend/network-protocol | A session-keyed, replay-proof envelope for cross-window messages, on any transport · docs |
| @hyperfrontend/builder | Bundles a TypeScript library into ESM, CJS, IIFE and UMD, and writes the manifest that ships with it · docs |
| @hyperfrontend/versioning | From conventional commits to the bump, the version and the changelog entry · docs |
| @hyperfrontend/project-scope | Reads a repository it has never seen, scores what it finds, and stages writes until you commit them · docs |
| @hyperfrontend/questions | Terminal prompts that return a value, never an exception · docs |
| @hyperfrontend/json-utils | JSON Schema validation that reports every violation at once, with the pointer that found it · docs |
| @hyperfrontend/ui-utils | DOM utilities that hand back their own teardown: styles, gestures, element lifecycle, colour · docs |
| @hyperfrontend/immutable-api-utils | Built-ins captured before untrusted code runs, and objects nothing can tamper with after · docs |
| @hyperfrontend/state-machine | The lifecycle of an async operation as a store, with the states a lone isLoading cannot tell apart · docs |
| @hyperfrontend/logging | Structured, levelled logging with channels and timers · docs |
| @hyperfrontend/cryptography | Password and key encryption with one call, the same in the browser and in Node.js · docs |
| @hyperfrontend/data-utils | Walk, compare and repair data structures, circular references included · docs |
| @hyperfrontend/time-utils | Timers that can be paused and resumed, intervals, and time normalisation · docs |
| @hyperfrontend/random-generator-utils | Seeded, reproducible random draws from real distributions, plus UUIDs · docs |
| @hyperfrontend/string-utils | Base64 and friends that encode UTF-8 first, identical in the browser and in Node.js · docs |
| @hyperfrontend/list-utils | FIFO and LIFO lists of objects held by reference, with the filtering and iteration to match · docs |
| @hyperfrontend/function-utils | Wrappers that change what a call does without changing what it looks like · docs |
- hyperfrontend.dev: the API reference generated from every library, the guides, the demos, site-wide search, and the articles with an Atom feed
- Architecture: how the libraries compose, and why the seams sit where they do
- Library compatibility: where every package runs and what it publishes, generated from the manifests
- Manifesto: why this exists, where it is going, and what it will not build
- Acknowledgments: the humans behind the code
Read the contributing guide for the development setup (GitHub Codespaces works out of the box), the contribution process, and the coding and commit conventions. Every contributor signs the Contributor License Agreement before a pull request can merge. If you use LLM assistance, REGARDING_AI.md describes how AI tooling is used here.
Report vulnerabilities through the security policy, never through a public issue.
Star the repository, write to the project with a question, or see FUNDING.md for ways to support the work.
 Andrew Redican 💻 📖 🚇 🚧 📆 🤔 |
 Brian Smith 🤔 |
|||||
Add your contributions
|
||||||
This project follows the all-contributors specification. Contributions of any kind are welcome.