What Ionify Enables

Capabilities are what you get. For how they are built, see Architecture. For why, see Philosophy.

Everything below is native. There is nothing to bolt on.

One Unified Pipeline

Development and production run through the same deterministic flow — not a dev server and a bundler duct-taped together.

Resolver → Dependency Publication → Graph → Transform → CAS → Planner → Output

What you run in development is what ships. An entire class of "works in dev, breaks in build" bugs disappears because there is only one pipeline to disagree with itself.

One Unified Authority

Verified work is owned once and consumed everywhere.

The dev server, the production build, federation, and vendor packs all read the same published authority instead of each deriving its own answer. When something has already been established and proven valid, no later stage rebuilds it.

This is the core of Ionify. The Architecture page explains the authorities that make it possible.

No Plugin Hell

In most toolchains, the things below are plugins you install, configure, and keep in sync. In Ionify they are native — and every plugin you don't install is one less place for dev and production to disagree.

  • No React plugin. React and React Fast Refresh work out of the box. No React plugin, no Refresh plugin, no JSX adapter.
  • No Federation plugin. Federation is part of the engine, not a separate runtime you wire up.
  • No Monorepo plugin. Ionify understands a workspace natively. No task-graph plugin to get cross-project reuse.
  • No TypeScript setup. Zero-config TS/TSX with infrastructure-level type awareness.

Native Monorepo

Ionify treats a workspace as one system with shared knowledge, not many projects that happen to share a folder.

Most workspace tooling reuses the result of a project's build — replay the whole output if nothing in that project changed. Ionify works one level deeper: it shares the knowledge used to produce the output — the graph, the dependency contracts, the transformed artifacts — across every project at once.

  • One shared graph across every project. Module identity, content hashes, and edges are established once and reused everywhere.
  • One shared ownership — a dependency's contract is published once for the whole workspace, not re-derived per project.
  • One shared authority — a single `.ionify/` authority state the entire workspace consumes.
  • One workspace. No monorepo plugin. Cross-project reuse is native; there is no task-graph plugin to install or configure.

Because reuse is by identity, it is granular and additive. Change one file and Ionify re-enters the graph at the affected node and re-establishes only what genuinely changed — every other project keeps consuming the parts whose identity still holds. Open one app, and the next is near-instant, because it consumes shared knowledge instead of rediscovering it.

Submodules are first-class. The same authority state reaches across Git submodule boundaries, so shared contracts and graph nodes are reused across submodules exactly as they are within a single repo.

Native Federation

Federation in Ionify is not runtime code-sharing bolted onto two independent builds. Host and remote share the same graph and the same authority — the workspace model, extended across application boundaries.

What that enables:

  • The base changes Module A → the remote immediately understands the change and consumes the new authoritative artifact. It does not re-derive its own version.
  • The remote changes → the base consumes the same authority without rebuilding duplicated work.
  • Shared packages stay singleton — React, React DOM, routing, and design systems are declared as singleton contracts instead of being bundled twice, so one runtime instance is shared rather than shipped by both sides.
  • Rebuilds stay targeted — a remote change invalidates the exact graph edge that changed, instead of leaking into unrelated host work.

The base and the remote never disagree about a shared dependency, because there is only one authority for it. The result is not just code sharing. It is authority sharing.

Faster CI

CI is where repeated build work hurts most, and how much of it you can avoid comes down to one thing: how coarse the unit of reuse is.

Task-level output caches reuse work in whole-task units. If nothing in a task changed, its stored output is replayed and nothing rebuilds. But the moment any input to that task changes, it is a full cache miss and the underlying tool rebuilds that project from zero. There is no partial credit inside the unit — change one file in a 500-module app and the whole app is cold again.

Ionify's unit of reuse is the identity, not the task: the specific modules, dependency contracts, chunks, and compression sidecars. A change invalidates only the identities it actually affects; everything else is still consumed by identity. The delta is re-established — the project is not.

A cache decides whether a task is reused. Authority decides how little has to be redone when it isn't.

  • Compress once, reuse forever. Compressed artifacts are stored by content identity. When something changes, only the invalidated parts are re-compressed — nothing re-compresses the whole output because one module moved.
  • Targeted invalidation. A change invalidates the exact identities it affects, so a run re-does the delta, not the project.
  • Across runs on a persistent runner — a CI runner that keeps its `.ionify/` authority state reuses verified work, including compression, between runs. Sharing that authority across different CI machines is what Cloud CAS (in progress) is for; until it ships, cross-machine reuse is not a claim we make.

See the Architecture for how compression fits "build once, reuse forever."

Hybrid Transformer

Ionify uses two transform engines inside one pipeline:

  • OXC by default — the fast path for modern JavaScript and TypeScript.
  • SWC as the authoritative fallback — for edge cases that need broader ecosystem coverage.

You never choose between speed and resilience. The engine routes each unit of work through the right path automatically.

Usage-Driven Pack Slimming

Not just tree-shaking — an architectural shift. Ionify learns what you actually use and progressively slims your payloads without ever blocking startup.

  • Persistent analysis — usage patterns live in the dependency graph, not discarded per build.
  • Content-addressed variants — slim variants are stored in CAS, so the same logic is never transformed twice.
  • Non-blocking — slimming happens in the background and upgrades the experience progressively.

Deterministic Performance

  • Identity-driven reuse — verified state is consumed by identity instead of repeating transformation, analysis, and publication.
  • Restart-safe — the persistent graph and CAS survive restarts and dev/build transitions, so warm work is not thrown away.
  • Deterministic artifacts — identical inputs always produce identical outputs across any environment.

On the Roadmap

  • Fast First Build (planned): reducing cold cost when no valid authority state exists yet.
  • Cloud CAS (in progress): verified artifacts moving across machines without reintroducing plural truth.
  • Infrastructure Health: proactive detection of bundle bloat and duplicate package versions.

Warm builds are validated. Cold builds are still improving. Fast First Build is planned. We would rather name that boundary than hide it.