1. Persistent Engine Architecture

Ionify is not a dev server plus a bundler. It is a single persistent engine.

  • One unified pipeline: resolver → graph → transforms → CAS → dev/build
  • Rust-powered native core (parse, transform, bundle)
  • Persistent dependency graph with version-aware invalidation
  • Content-addressable transform cache (restart-safe & deterministic)
  • Hybrid transform engine (OXC primary, SWC fallback)

Dev and production share the same semantics — no split-brain behavior.

2. Progressive Vendor Optimization (Few-Request Dev Mode)

Ionify keeps cold start light — and makes warm start minimal.

  • Core-only startup (fast initial serve)
  • Background feature pack builds (non-blocking)
  • AST-based import rewrite → pack routing (v2)
  • Chunk-group isolation (no duplicated runtimes)
  • Restart-safe pack activation
  • True few-request warm mode (dozens of deps → few files)

Optimization improves over time without blocking iteration.

3. Usage-Driven Pack Slimming

Ionify's pack slimming is not tree-shaking v1 — it's architecturally different from anything in the Vite/Rollup/esbuild ecosystem.

The real architectural difference

Ionify packSlimming Vite tree-shaking
analysis lifetime persistent per build
stored yes no
reuse across restart yes no
reuse across dev/build yes no
CAS-backed yes no

How it works

  • Project-wide usage scan (named + default imports) → deterministic `deps-usage.v1.json`
  • Content-addressed slim variants (usage-hash CAS keys)
  • Background slimming of manual and auto-detected feature packs
  • Deterministic precedence: slim pack → base pack → `/@deps/*` fallback
  • Safe gates: only slims when `package.json#sideEffects === false`; skips namespace imports
  • Chunk-aware `vendor-pack.v2.index.json` maps dep imports to the right pack files (base + slim)
  • No-duplication policy: deps covered by a pack are never served as separate shared chunks
  • Restart-safe activation: same `depsHash` + same usage index → identical filenames across restarts

Why this isn't "tree-shaking v1"

Traditional tree-shaking (Vite/Rollup/esbuild) runs once per build, discards its analysis, and starts over next time. Ionify persists usage analysis in the dependency graph, caches slim variants in the CAS, and reuses them across restarts, dev sessions, and production builds. The engine doesn't just remove dead code — it learns what you actually use and progressively produces smaller payloads without ever blocking startup.

Ionify doesn’t just prebundle — it learns what you actually use.

4. Deterministic Dependency Model

Correctness is structural, not patched at runtime.

  • Deterministic stable wrapper file names
  • Version-scoped deps manifests
  • ESM + CJS interop with synthesized export surfaces
  • "package.json#exports" and "#browser" resolution parity
  • Default and namespace interop correctness
  • CSS request-mode parity ("?inline", "?raw", "?url")
  • Transitive dependency self-healing on restart

No hidden runtime guards. No accidental export mismatches.

5. Performance Model

Performance is observable and restart-safe.

  • Version-isolated caches
  • Deterministic request graph shaping
  • Background optimization jobs
  • No rebuild drift across restarts
  • Identical artifacts for identical inputs

Cold stays light. Warm gets leaner.

6. Workspace Engine

Ionify works across apps — not just inside one.

  • Monorepo + Git submodule support with shared `.ionify/` state
  • Cross-app pack reuse: open one app, the next is near-instant
  • Deterministic workspace module IDs (`ws://...`) — no absolute-path leakage
  • CAS-first hydration across dev, build, and test
  • `ionify build` with production packs preflight, CAS hit/miss metrics, and deterministic outputs
  • `ionify analyze` exposes request/byte savings per pack

One workspace. Shared knowledge. No wasted work.

7. Developer Experience

Powerful engine. Minimal friction.

  • Native dev server + SSE HMR
  • React Fast Refresh out of the box
  • TypeScript-first pipeline (TS/TSX zero-config)
  • Structured error overlay (build vs runtime)

What's Next

  • Dependency analyzer: visualize the tree and identify bloat from the CLI
  • Bundle bloat detection with lighter-alternative suggestions
  • Duplicate package detection across versions
  • Telemetry foundation for AI-assisted optimization