Post

statorjs.dev
@statorjs.dev

Confirmed: version numbers really are cheap 🏷️ #StatorJS 2.5 is out 🚀 five minors since 2.0. Each one small, but together they round out what production apps need: real security primitives, first-party middleware, and a CLI that owns the toolchain. statorjs.dev

statorjs.devStator · the server-canonical JavaScript framework built on state machinesA web framework where state machines are the unit of composition and the DOM renders where its state lives — almost always the server.

2 reposts2 likes

statorjs.dev
@statorjs.dev

The security round: a machine can now declare events no client may ever send. serverOnly: ['CHARGE_APPROVED'] A forged approval is rejected at the wire, never processed as truth. The machine definition stays the complete list of what can happen, and now of who may cause it.

statorjs.dev
@statorjs.dev

Middleware is a file, not config. middleware.ts covers every route by position, and the framework's security defaults always run first. Stator's built-in CSRF guard was the proving case: it's now crossSiteGuard(), first-party middleware alongside cors() and securityHeaders().

statorjs.dev
@statorjs.dev

The hand-written server.ts is gone. stator dev / build / start / check / test, with typed config in stator.config.ts. Our favorite part: stator build runs stator check first, a full server-stack typecheck, so a broken server import fails the build instead of shipping silently.

statorjs.dev
@statorjs.dev

2.5 itself adds the seam the CLI made necessary: boot.ts. defineBoot hosts server-lifetime work, query config at startup, run the poll or subscription that feeds your machines, tear down on shutdown. Boot is a source, not a controller. Policy stays in the machine, where it's testable.