Skip to content

Production Readiness

Chris Michael edited this page Jul 26, 2026 · 4 revisions

Effuse

Production Readiness

Status: Effuse is experimental and is not presented as production-ready.

Production-oriented engineering exists in the repository, but a green test suite is not the same as a stable framework contract.

Current Evidence

Area Current evidence
Runtime Core unit and integration tests cover reactivity, rendering, layers, SSR, and diagnostics.
Package gate pnpm test executes all ten publishable package suites; a repository contract rejects missing or failure-masking test commands.
Router Matching, guards, nested views, aliases, grouped routes, and dynamic segments are tested through the root gate.
Type safety Workspace TypeScript checking is a merge gate.
Lint Core uses a zero-warning ESLint gate.
Builds Packages build through pnpm; the integration app is checked with Bun.
Browser dogfood An ignored local app exercises framework packages and real workflows.
CI Pull requests run lint, typecheck, every package test suite, repository contract tests, builds, and integration-app checks on the supported Node runtime.
Server Validation, typed failures, middleware metadata, manifests, and clients have regression coverage.
Output safety SSR escapes text and attributes; hydration JSON is escaped against script break-out. @effuse/ink sanitizes link/image URLs (blocking javascript:/data:text/html and entity-encoded bypasses), and @effuse/i18n rejects __proto__/constructor/prototype keys when merging and looking up remote-loaded translations.

Boundaries Before A Stable Claim

  • Publish a complete, versioned documentation set aligned with current APIs.
  • Finish the unified route manifest design in #218.
  • Define supported server adapters and deployment targets.
  • Establish compatibility, deprecation, security, and release policies.
  • Promote representative applications from local dogfood into repeatable public compatibility fixtures where appropriate.
  • Add performance budgets and long-running reliability evidence.

Compatibility Policy Today

Minor releases may change experimental APIs. Prefer exported package entry points over internal paths. Treat services as the primary layer term; provides is compatibility syntax. Treat alias layer bindings as the primary component and hook access model.

Operational Rule

Do not infer support from a type that happens to compile. Verify the package export, runtime test, and documented status. Planned behavior is not available behavior.

Clone this wiki locally