fix(orm): type parameterized computed field args from the field's params metadata - #2828
Conversation
…ams metadata `ComputedFieldArgs` read the args type off the generated `computedFields` stub, whose non-scalar params (enums, type defs, models, Json) were emitted as `unknown`. A wrong enum value or type-def shape therefore compiled in `select`/`where`/`orderBy`, the aggregate inputs and the generated `input.ts` types, and the implementation callback saw `unknown` too, while zod already validated the args precisely at runtime. - derive `ComputedFieldArgs` from the field's `params` metadata with the same mapping procedures use (enums -> value union, type defs -> object shape, optional -> optional key), and make `ComputedFieldsOptions` read the same source so implementation and query typing can't drift - generator: name the stub param `_args` (the old name tripped `noUnusedParameters` in consuming projects) and emit enum params as the enum value union read off the schema's own `enums` member - tests: runtime + compile-time e2e coverage for enum and type-def params, and a parameterized enum-param field in the typing schema Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (12)
💤 Files with no reviewable changes (7)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughChangesSchema-driven computed fields
Estimated code review effort: 3 (Moderate) | ~30 minutes Merge Risk: ⚪ Minimal · up to The computed-field metadata transition is consistent across generation, typing, runtime validation, and query handling. No merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 ESLint
packages/orm/src/client/client-impl.tsESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. packages/orm/src/client/crud/dialects/base-dialect.tsESLint skipped: the matched ESLint configuration already failed (missing-dependency). packages/orm/src/client/options.tsESLint skipped: the matched ESLint configuration already failed (missing-dependency).
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
`count(*)` is a bigint on Postgres, which the `pg` driver returns as a string, so the plain-select assertion compared `'2'` with `2` on the postgresql CI matrix. Normalize via `Number()` before comparing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The return type was the last thing read off the generated stub, and it is available on the field definition too (`type`/`optional`/`array`), so drop the stub from the generated schema entirely and derive everything about a computed field from its field def: - `ComputedFieldsOptions` keys off fields with `computed: true` (excluding delegate-inherited ones, which are configured on the base model) and maps the implementation's return type from the field's declared type with the same mapping the stub used (scalars to JS types, Decimal as number, everything else `unknown`, `| null` for optional, `[]` for lists) - the runtime config validation and the "computed fields need an explicit select" join check read the field defs instead of `modelDef.computedFields` - `ModelDef.computedFields` is removed from the schema type and the generator no longer emits the stub (nor the enum-typed `_args` for it) - regenerate the checked-in schemas that carried the stub - e2e: assert the implementation's return type is still enforced Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Problem
argsof a parameterized computed field were typed off the generatedcomputedFieldsstub, whose non-scalar params (enums, type defs, models,Json) are emitted asunknown. So forall of these compiled, and the implementation callback saw
args.status/args.filterasunknown:Runtime zod validation was already precise (it builds the args schema from the field's
params), so typing and validation had drifted apart.Fix
ComputedFieldArgsnow derives from the field'sparamsmetadata, reusing the param mapping procedures already use (MapParamsObject/MapParam, renamed from the procedure-specific names): scalars → TS types, enums → value union, type defs → object shape, optional → optional key.ComputedFieldsOptionsreads the same source, so the implementation signature and the query input types can't disagree. This also covers parameterized computed fields inherited by delegate sub-models (their field defs carryparams)._args(the bareargstrippednoUnusedParametersin consuming projects), and enum params in the stub are emitted asSchemaType["enums"]["X"]["values"][keyof ...]instead ofunknown. Type-def params remainunknownin the stub only, sinceschema.tshas no TS type for type defs; the ORM/input.tstyping resolves them precisely.Tests
computed-fields.test.ts: a runtime test with enum + type-def params (including zod rejection of a wrong enum value and a wrong type-def payload), and a compile-time test asserting wrongargsfail inselect/where/orderBy, in the implementation callback, and in the generatedUserSelect/UserWhereInputtypes.hasStatus(status: Status) Boolean @computedwith@ts-expect-errorassertions intypecheck.ts.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Tests