Summary
stash eql install --eql-version 3 --drizzle fails:
`--eql-version 3` does not support `--drizzle` yet — v3 currently installs via the direct path only.
validateInstallFlags (packages/cli/src/commands/db/install.ts:643-658) rejects --eql-version 3 in combination with --drizzle, --migration, --latest, and --migrations-dir.
The result is that a Drizzle user on EQL v3 has no supported way to get EQL into their migration history. Their only option is a direct install against a live database, which:
- does not survive a database rebuild from migrations,
- is not reproducible across environments (local, CI, preview branches, production),
- leaves the schema history not describing the schema.
--migration has the same consequence for Supabase users, who lose EQL on every supabase db reset.
Why this is awkward
The rest of the v3 Drizzle surface is shipped. @cipherstash/stack/eql/v3/drizzle exists and is a package export, with column.ts, operators.ts, codec.ts, sql-dialect.ts, and schema-extraction.ts. So a user can write v3 Drizzle queries but cannot install v3 through a Drizzle migration.
Expected
--eql-version 3 --drizzle generates a Drizzle migration containing the v3 install SQL, the same way --eql-version 2 --drizzle does today.
Similarly --eql-version 3 --migration should write a Supabase migration file.
The v3 install is a single idempotent SQL script, so the constraint doesn't look intrinsic. If there is a reason the script can't be emitted into a migration (search_path assumptions, transaction wrapping, the operator-family probe needing to run against a live connection), that reason is worth capturing in the guard's error message and in the docs.
Impact on docs
The Supabase Fundamentals page previously recommended committing the install script as the earliest migration. That path is v2-only, so it has been removed and replaced with a warning that a v3 install does not survive supabase db reset. The Drizzle integration page will need the same treatment.
Repro
npx stash eql install --eql-version 3 --drizzle
# → `--eql-version 3` does not support `--drizzle` yet — v3 currently installs via the direct path only.
npx stash eql install --eql-version 3 --supabase --migration
# → `--eql-version 3` does not support `--migration` yet — …
Summary
stash eql install --eql-version 3 --drizzlefails:validateInstallFlags(packages/cli/src/commands/db/install.ts:643-658) rejects--eql-version 3in combination with--drizzle,--migration,--latest, and--migrations-dir.The result is that a Drizzle user on EQL v3 has no supported way to get EQL into their migration history. Their only option is a direct install against a live database, which:
--migrationhas the same consequence for Supabase users, who lose EQL on everysupabase db reset.Why this is awkward
The rest of the v3 Drizzle surface is shipped.
@cipherstash/stack/eql/v3/drizzleexists and is a package export, withcolumn.ts,operators.ts,codec.ts,sql-dialect.ts, andschema-extraction.ts. So a user can write v3 Drizzle queries but cannot install v3 through a Drizzle migration.Expected
--eql-version 3 --drizzlegenerates a Drizzle migration containing the v3 install SQL, the same way--eql-version 2 --drizzledoes today.Similarly
--eql-version 3 --migrationshould write a Supabase migration file.The v3 install is a single idempotent SQL script, so the constraint doesn't look intrinsic. If there is a reason the script can't be emitted into a migration (search_path assumptions, transaction wrapping, the operator-family probe needing to run against a live connection), that reason is worth capturing in the guard's error message and in the docs.
Impact on docs
The Supabase Fundamentals page previously recommended committing the install script as the earliest migration. That path is v2-only, so it has been removed and replaced with a warning that a v3 install does not survive
supabase db reset. The Drizzle integration page will need the same treatment.Repro