@voltro/protocol 0.2.0 → 0.2.2

package/CHANGELOG.md

@@ -39,6 +39,30 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.2.2] — 2026-07-17
+
+### Added
+
+- **@voltro/cli** — `voltro build` now precompiles the whole serve path (framework + effect + `@voltro` inlined, app modules as lazy chunks) into a single **serve bundle** (`.framework/dist-api/serveBundle/serveEntry.js`), and `voltro serve` boots from it in-process — no child `node --import tsx`, no CLI command graph, no per-module resolution of the ~2700-module framework graph. This cuts `serve: ready` from ~1000 ms to ~180 ms (~5–6×) on both driverless (memory) and driver-backed (postgres) apps; the win is larger on a cold scale-to-zero container where module resolution dominates. The app's declared SQL driver is inlined into the bundle so it shares the framework's single effect instance (only the native leaf like `pg` stays external, resolved at runtime so it survives the deploy relocation). Fully fallback-safe: a missing, stale, or corrupt bundle degrades to the standard tsx serve path, so it can never stop `voltro serve` from booting. Nothing to configure — building an API app produces the bundle and serving prefers it automatically.
+
+### Fixed
+
+- **@voltro/database** — The core-table registry (`registerCoreTables` / `requireActors` / `requireTenants`) now stores its state on a process-global `Symbol.for` singleton, the same mechanism the main table registry already uses — instead of module-local `let` bindings. Module-local state splits when the `@voltro/database` module is duplicated in a process (e.g. resolved through both the `.` and `./sql` entry points, or a bundled framework copy alongside an externally-resolved one): one instance's `registerCoreTables` becomes invisible to the instance that reads it, surfacing as a spurious `core 'actors' table not registered` at store construction. Pinning it to `globalThis` makes every copy share one store, matching the table registry's already-global behaviour.
+
+### Internal (no consumer-facing effect)
+
+- **@voltro/cli** — `appModuleLoader` now accepts lazy `() => import()` loaders alongside eager module namespaces (the eager path — today's `apiEntry.js` bundle — is unchanged). Groundwork for the serve bundle: app modules registered as lazy loaders evaluate on first `importAppModule` (during `runServe`, after `registerCoreTables`) rather than eagerly at bundle-import time. No consumer-facing effect on its own.
+
+---
+
+## [0.2.1] — 2026-07-17
+
+### Fixed
+
+- **@voltro/cli, @voltro/database** — `voltro codegen` / `dev` / `serve` / `build` no longer crash with `Cannot find package '@voltro/sql-mysql'` on an app that doesn't declare that driver (e.g. a memory-store app, or a postgres app for the mysql/mssql drivers). The CLI's framework-table assembly statically imported the CDC-offsets table schema from `@voltro/sql-mysql` / `@voltro/sql-mssql` (`import { _voltroCdcOffsetsTable } from '@voltro/sql-mysql'`), so merely LOADING the CLI resolved those driver packages — failing whenever one wasn't installed. This surfaced only in a production install where the drivers aren't present (0.2.0's app-declared-driver change), not in the workspace where all drivers are devDependencies. The two CDC-offsets table schemas (pure schema, no driver runtime) move to `@voltro/database` — the driver-agnostic package both the CLI and the drivers already depend on; the drivers re-export them so their public API + CDC readers are unchanged. The CLI now references a SQL driver only through the runtime `importDriver()` lookup (lazy, and only for the dialect actually in use). The lazily-imported driver modules are also typed with local structural interfaces instead of `typeof import('@voltro/sql-*')`, so no driver package is referenced in a type position either.
+
+---
+
 ## [0.2.0] — 2026-07-17
 
 ### ⚠ BREAKING

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/protocol",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "The Voltro wire + plugin contract — defineQuery/Mutation/Action/Stream, definePlugin, sessions / JWT / API-keys, and the RPC protocol.",
   "keywords": [
     "voltro",
@@ -53,7 +53,7 @@
   },
   "dependencies": {
     "@effect/sql": "^0.51.1",
-    "@voltro/database": "0.2.0",
+    "@voltro/database": "0.2.2",
     "jose": "^6.2.3"
   },
   "peerDependencies": {