Summary
@cipherstash/prisma-next has excellent type-level tests proving that EQL v3 query operators are capability-gated at compile time — e.g. packages/prisma-next/test/operation-types.types.test-d.ts asserts (via @ts-expect-error) that:
eqlEq does not surface on storage-only eql_v3_boolean / eql_v3_text
eqlMatch does not surface on eql_v3_text_eq (no free-text index)
eqlGt does not surface on eql_v3_double_eq (no order/range)
These currently pass (each @ts-expect-error is satisfied), so the capability gating is real. But two gaps mean nothing enforces it going forward:
pnpm --filter @cipherstash/prisma-next typecheck is currently red — ~38 errors, all unrelated implicit-any (TS7006 / TS7031 / TS7053) in test/v3/properties.test.ts, integration/adapter.ts, and several test/live/* files. None are in the capability test files, but they fail the whole tsc --noEmit run.
typecheck isn't wired into any CI workflow (no .github/workflows/* runs the prisma-next typecheck script). So even once it's green, a regression that makes an unsupported operator type-check (silently removing the gating) would not be caught.
Why it matters
The .test-d.ts @ts-expect-error assertions are only enforced when tsc actually processes them. Right now they're aspirational: a future change that made eqlGt available on a non-ord column would flip an @ts-expect-error from 'used' to 'unused' — which is itself a tsc error — but only if typecheck runs and is required. Today it neither passes nor runs in CI.
Suggested fix
- Fix the ~38 implicit-
any errors (add annotations / satisfies) so typecheck is green.
- Add a
typecheck step to the prisma-next CI job (or the shared type-check job) so .test-d.ts capability assertions become a required, enforced check.
Context
Surfaced while reviewing the prisma-next EQL v3 work (#655) and the CLI skill companion (#683) — the skill documents 'unsupported operators are a compile error', which is true today but not CI-guarded.
https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w
Summary
@cipherstash/prisma-nexthas excellent type-level tests proving that EQL v3 query operators are capability-gated at compile time — e.g.packages/prisma-next/test/operation-types.types.test-d.tsasserts (via@ts-expect-error) that:eqlEqdoes not surface on storage-onlyeql_v3_boolean/eql_v3_texteqlMatchdoes not surface oneql_v3_text_eq(no free-text index)eqlGtdoes not surface oneql_v3_double_eq(no order/range)These currently pass (each
@ts-expect-erroris satisfied), so the capability gating is real. But two gaps mean nothing enforces it going forward:pnpm --filter @cipherstash/prisma-next typecheckis currently red — ~38 errors, all unrelated implicit-any(TS7006 / TS7031 / TS7053) intest/v3/properties.test.ts,integration/adapter.ts, and severaltest/live/*files. None are in the capability test files, but they fail the wholetsc --noEmitrun.typecheckisn't wired into any CI workflow (no.github/workflows/*runs the prisma-nexttypecheckscript). So even once it's green, a regression that makes an unsupported operator type-check (silently removing the gating) would not be caught.Why it matters
The
.test-d.ts@ts-expect-errorassertions are only enforced whentscactually processes them. Right now they're aspirational: a future change that madeeqlGtavailable on a non-ord column would flip an@ts-expect-errorfrom 'used' to 'unused' — which is itself a tsc error — but only iftypecheckruns and is required. Today it neither passes nor runs in CI.Suggested fix
anyerrors (add annotations /satisfies) sotypecheckis green.typecheckstep to the prisma-next CI job (or the shared type-check job) so.test-d.tscapability assertions become a required, enforced check.Context
Surfaced while reviewing the prisma-next EQL v3 work (#655) and the CLI skill companion (#683) — the skill documents 'unsupported operators are a compile error', which is true today but not CI-guarded.
https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w