@voltro/protocol 0.1.6 → 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +16 -0
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -39,6 +39,22 @@ _Changes staged for the next release accumulate here (rolled up from
|
|
|
39
39
|
|
|
40
40
|
---
|
|
41
41
|
|
|
42
|
+
## [0.2.1] — 2026-07-17
|
|
43
|
+
|
|
44
|
+
### Fixed
|
|
45
|
+
|
|
46
|
+
- **@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.
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## [0.2.0] — 2026-07-17
|
|
51
|
+
|
|
52
|
+
### ⚠ BREAKING
|
|
53
|
+
|
|
54
|
+
- **@voltro/cli** — The SQL dialect drivers (`@voltro/sql-postgres`, `@voltro/sql-mysql`, `@voltro/sql-mssql`, `@voltro/sql-sqlite`, `@voltro/sql-turso`) are no longer dependencies of `@voltro/cli`. Each app now declares the driver for its own DB dialect as a dependency, and `voltro dev`/`serve`/`migrate` resolve it from the app root. This keeps every driver — including turso's ~90 MB native binary — out of the production image of an app that doesn't use it: a `store: 'memory'` app ships no SQL driver at all, and a postgres app ships only `@voltro/sql-postgres`. Combined with a `pnpm --prod deploy`-based Dockerfile (the standalone/template Dockerfiles now do this), a memory-API image drops its `node_modules` from ~477 MB to ~330 MB. **Migration:** add the driver for your dialect to the app that uses it — `pnpm add @voltro/sql-postgres` (or `-mysql` for mysql/mariadb, `-mssql`, `-sqlite`, `-turso`). A memory store needs none. Scaffolded projects already declare it, and `voltro add mssql` adds `@voltro/sql-mssql` automatically. If the driver is missing at boot, `voltro serve` now fails with a message naming the exact package to install instead of an opaque module-not-found.
|
|
55
|
+
|
|
56
|
+
---
|
|
57
|
+
|
|
42
58
|
## [0.1.6] — 2026-07-17
|
|
43
59
|
|
|
44
60
|
### Added
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@voltro/protocol",
|
|
3
|
-
"version": "0.1
|
|
3
|
+
"version": "0.2.1",
|
|
4
4
|
"description": "The Voltro wire + plugin contract — defineQuery/Mutation/Action/Stream, definePlugin, sessions / JWT / API-keys, and the RPC protocol.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"voltro",
|
|
@@ -53,7 +53,7 @@
|
|
|
53
53
|
},
|
|
54
54
|
"dependencies": {
|
|
55
55
|
"@effect/sql": "^0.51.1",
|
|
56
|
-
"@voltro/database": "0.1
|
|
56
|
+
"@voltro/database": "0.2.1",
|
|
57
57
|
"jose": "^6.2.3"
|
|
58
58
|
},
|
|
59
59
|
"peerDependencies": {
|