Clintchiz
57097c8204
Fix round 2 for Task 14, addressing a critical review finding reproduced on
a real built server.
C1 (critical): the generated production entry set the authz catalog inside
createProductionServer's BODY, but ES modules evaluate every static import
(including app middleware, emitted as a static import) before the importing
module's body runs. Middleware reading getAuthzCatalog() at module scope —
the same eager shape authzMiddleware({ catalog, ... }) itself requires, and
the pattern app/middleware/logger.ts's `export default requestLogger({...})`
already uses — saw an unset catalog and crashed the whole process at import
time, after every other gate (typecheck/lint/tests/a plain `bun run build`)
stayed green.
Fix: packages/cli/src/build.ts now emits a small side-effecting
`.authz-setup.ts` module containing the static imports of every
app/authz/*.ts declaration plus a call to the new
applyAuthzManifestEarly(entries) (packages/dev-server/src/prod.ts), and
imports THAT MODULE FIRST in the generated entry — before pages, api,
realtime, middleware, components, and layouts. applyAuthzManifestEarly is
deliberately silent (no missing-default-export warnings, though a genuine
conflict still throws and fails the boot at import time); createProductionHandlers
keeps its own unconditional merge+set as an idempotent, always-warning second
pass, so an adapter that bypasses the generated entry and calls it directly
still gets a correctly merged, validated catalog, and so the function stays
independently testable.
I3: corrected packages/authz/src/client.ts's WRN-AUTHZ-SETUP message, which
claimed prod always sets the catalog before middleware runs — true again for
the generated entry after the C1 fix, but not for a custom entry that calls
createProductionHandlers directly.
I2: dev HMR editing app/authz/*.ts reloaded the page while the OLD catalog
stayed authoritative (watch.ts classifies any non-CSS change as "server";
hotUpdate had no authz/ branch) — a false security signal, since tightening
or removing a permission looked like it took effect but didn't until a
restart. Added the branch (packages/dev-server/src/index.ts), and gave
loadAppAuthzCatalog (authz-boot.ts) an injectable importer: a raw import()
would have silently no-op'd on the re-import (Bun caches local TS/JS modules
by filesystem path and ignores query strings), so the hot path routes through
loadModule (pipeline.ts) instead, which copies the edited file to a versioned
sibling specifically to defeat that cache.
I4: added direct createProductionHandlers/applyAuthzManifestEarly tests
(packages/dev-server/test/authz-prod.test.ts: conflict throws naming both
files, missing default export warns and skips, empty array yields an empty
catalog, a second call re-validates rather than trusting a stale singleton)
and the regression test that matters most
(packages/cli/test/authz-prod-coldstart.test.ts): a real `runBuild` + a real
`bun dist/server.js` boot, with a middleware module reading
getAuthzCatalog() at module scope, asserting it actually serves a request.
M5: startServer built its own router once, then loadAppAuthzCatalog built a
second one from scratch on every dev boot and every authz/ hot reload.
loadAppAuthzCatalog now accepts either an appDir (still used standalone, e.g.
by the test suite) or an already-built Router, and both call sites in
index.ts now pass the router they already have.
Every fix in this round was verified non-vacuous by sabotaging it and
confirming the corresponding test fails, then reverting.
WRNexusJS
WRNexusJS is a compiler-driven, SSR-first, Bun-native full-stack framework for building secure, fast, maintainable applications with .wrn pages, layouts, components, stores, server functions, client functions, typed outputs, APIs, validation, authentication, realtime rooms, and production tooling.
Current framework version: 0.8.0
Core principles
- Secure by default with CSP, CSRF, safe serialization, URL policies, request limits, SSRF protection, secret scanning, and release gates.
- Performance-first SSR with zero framework JavaScript for static pages and selective hydration for interactive pages.
- One compiler-understood
.wrnmodel for markup, props, state, outputs, and runtime-specific functions. - Backward-compatible package upgrades with migrations, generated references, validation scripts, and private publishing controls.
- Package kits that give developers public helpers, package tests, documentation, and complete UI blocks where a package has a developer-facing interface.
Quick start
bun install
bun run validate:0.8
bun run check
bun run dev
Create or upgrade a project:
bunx @wrnexus/cli@0.8.0 create my-app
bunx @wrnexus/cli@0.8.0 update --version=0.8.0 --report
Package kits in 0.8
All 39 framework packages expose a documented helper/API surface and package tests. UI-facing packages additionally own complete .wrn blocks composed from @wrnexus/ui:
@wrnexus/auth— complete account, sign-in, sign-up, MFA, passkey, recovery, device, provider, and security blocks.@wrnexus/captcha— challenge, field, status, extraction, verification, response, and context helpers.@wrnexus/i18n— recursive locale loading, fallback chains, request resolution, SSR/browser translations, language controls, and formatters.@wrnexus/image— responsive picture plans, secure loaders, placeholders, preload hints, audits, and image blocks.@wrnexus/realtime— typed messages, room connections, presence, typing, metadata, composer, status, and message blocks.@wrnexus/uploader— upload attributes, result validation, formatting, dropzone, and status blocks.@wrnexus/validation— parse/throw helpers, consistent error responses, summaries, and field errors.@wrnexus/ui— the complete shared design-system component catalog.
Infrastructure packages remain helper/API-only so database, encryption, security, compiler, server, and build packages do not pull browser UI into production server code.
Security note for encrypted HTTP bodies
@wrnexus/encryption supports authenticated application-layer request and response envelopes with method, path, request-ID, timestamp, expiry, key-rotation, body-size, and replay binding.
This feature does not replace HTTPS. It is appropriate for service-to-service calls, native/mobile clients, controlled agents, or selected fields with server-managed keys. It cannot hide data from an end user when a browser receives the decryption key.
Validation commands
bun run audit:packages
bun run test:package-kits
bun run validate:0.8
bun run security:framework
bun run sbom
bun run benchmark:framework
bun run validate:staging
bun run check