feat: add option to inject params in generated zod schemas - #3475
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a new override.zod.params mutator that is normalized and threaded into Zod schema generation so a user-provided function can produce per-validator params arguments using build-time context (operation, location, schema name, fieldPath, validator). ChangesZod params injection feature
Sequence DiagramsequenceDiagram
participant User as User Config
participant Orval as Orval Generator
participant Parser as parseZodValidationSchemaDefinition
participant Mutator as paramsMutator
participant Output as Generated Code
User->>Orval: Provide override.zod.params function
Orval->>Orval: normalizeMutator(workspace, zod.params)
Orval->>Parser: parseZodValidationSchemaDefinition(schema, paramsInjection)
Parser->>Parser: Thread fieldPath through property parsing
Parser->>Mutator: buildParamsArg({operationId, location, schemaName, fieldPath, validator})
Mutator->>Mutator: Invoke user params function with context
Mutator-->>Parser: Return params object or undefined
Parser->>Output: Emit validator call with merged or appended params
Output-->>User: Generated zod.* validator calls with params
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/content/docs/reference/configuration/output.mdx`:
- Line 1142: The sentence and example conflict: change either the wording or the
example so they match; for clarity update the text that currently says
“returning a plain string” to instead say “returning a plain object” when
showing the example `return { error: 'My message' }`, or replace the example
with a plain-string return like `return 'My message'` so the wording “plain
string” is accurate—ensure the doc line referencing the static message behavior
and the example are consistent.
In `@packages/zod/src/index.ts`:
- Around line 2167-2170: The mutators export currently only includes
preprocessResponse and paramsMutator, but the emitter can generate
preprocessParams, preprocessQueryParams, preprocessHeader, and preprocessBody
identifiers; update the mutators array to also conditionally include each of
preprocessParams, preprocessQueryParams, preprocessHeader, and preprocessBody
(e.g., ...(preprocessParams ? [preprocessParams] : []), etc.) so every possible
preprocess* hook emitted by the schema generator is returned and importable.
- Around line 1945-1956: The injected params context currently uses the
transformed operationName (via pascalOperationName) for operationId inside
makeParamsInjection, which is incorrect; change the operationId field to use the
original OpenAPI operationId (e.g. operation.operationId or the raw operationId
variable provided by the surrounding scope) instead of operationName so
zod.params consumers receive the real OpenAPI identifier while leaving
schemaName as `${pascalOperationName}${schemaSuffix}` and keeping paramsMutator
logic unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: abac7926-6a6c-4e38-8ad4-78e238af1f67
📒 Files selected for processing (5)
docs/content/docs/reference/configuration/output.mdxpackages/core/src/types.tspackages/orval/src/utils/options.tspackages/zod/src/index.tspackages/zod/src/zod.test.ts
82a1d5d to
f0afbe0
Compare
|
Actionable comments posted: 0 |
f0afbe0 to
594e7e4
Compare
|
Fixed relevant CodeRabbit comments |
|
Actionable comments posted: 0 |
|
cc @wadakatu thoughts? |
|
@z4o4z wouldn't mind your thoughts on this too |
z4o4z
left a comment
z4o4z
left a comment
There was a problem hiding this comment.
Solid PR — the API mirrors the existing preprocess Mutator pattern, the modifier / nullary skip lists are well-targeted, and the iso.datetime / iso.time merge special-case is exactly right. Docs include a concrete example and there are 7 unit tests covering the parser-level injection.
One structural item I'd want resolved before merge (left inline near makeParamsInjection): override.zod.params is currently wired only into operation-schema generation (generateZodRoute). Component (reusable-schema) generation has no parallel call, so when paired with generateReusableSchemas: true the named component validators emit without injection — quietly missing the case where the feature compounds the most.
The other items left inline are improvements (signature length, generated-output verbosity, a fieldPath note for array/tuple/rest, missing test shapes), not blockers.
| : undefined; | ||
|
|
||
| const pascalOperationName = pascal(operationName); | ||
| const makeParamsInjection = ( |
There was a problem hiding this comment.
Major — this makeParamsInjection (and the paramsMutator setup above) is wired only into generateZodRoute. Component / reusable-schema generation — generateReusableSchemaSet in packages/orval/src/reusable-schemas.ts, plus generateZodSchemasInlineReusable / writeZodSchemasReusable in packages/orval/src/write-zod-specs.ts — has no parallel call. So when a user pairs override.zod.params with override.zod.generateReusableSchemas: true, the operation wrappers get zodParams(...) injected but the actual named component validators (Pet, Owner, …) — referenced by N operations — emit without it. That's a quiet hole exactly where the feature's value compounds.
Two reasonable resolutions:
- Plumb a
ZodParamsInjectionthrough the reusable writer (likely withoperationId: ''/ alocation: 'schema'sentinel so user-sidezodParamscan branch on it), mirroring howGenerateReusableSchemaSetOptionsalready threadsstrict/coerce/isZodV4. - Or scope it out explicitly in the docs (the current copy reads 'into every generated validator' without qualification).
There was a problem hiding this comment.
Agreed that this is indeed lacking. I'll make the required changes to also include the param injection in those places
| const arrayArgs = args as ZodValidationSchemaDefinition; | ||
| const value = arrayArgs.functions | ||
| .map((prop: [string, unknown]) => parseProperty(prop)) | ||
| .map((prop: [string, unknown]) => parseProperty(prop, fieldPath)) |
There was a problem hiding this comment.
Minor — array (here), tuple (~L1252), and rest (~L1262) all recurse with parseProperty(prop, fieldPath) unchanged, so { tags: array<string> } and { tags: string } both yield the inner string's fieldPath: ['tags']. The validator field disambiguates the container ('array') from the element ('string'), but two tuple positions can't be distinguished, and a user-side i18n key can't tell element-level constraints from container-level ones.
Probably acceptable — it matches Zod's own issue.path, which also drops array indices — but worth a sentence in the docs alongside the existing scope explanation, or a future-proofing [] / 0 segment behind an option.
There was a problem hiding this comment.
I'll specify this in the docs
| strict: boolean, | ||
| isZodV4: boolean, | ||
| preprocess?: GeneratorMutator, | ||
| paramsInjection?: ZodParamsInjection, |
There was a problem hiding this comment.
Nit — paramsInjection is the 7th positional arg to parseZodValidationSchemaDefinition. The signature is already long (coerceTypes, strict, isZodV4, preprocess, paramsInjection); each new opt-in adds another. Not a blocker for this PR, but at this point an options-object overload would age better and let future fields land without breaking call sites.
There was a problem hiding this comment.
I wouldn't touch this for now as it will increase the complexity of this PR beyond it's original scope, but happy to pick it up later on
|
|
||
| const formattedArgs = formatFunctionArgs(args); | ||
| const paramsArg = buildParamsArg(fn, fieldPath); | ||
| let combinedArgs: string; |
There was a problem hiding this comment.
Two small nits:
-
buildParamsArg(above, ~L1037–1049) inlinesJSON.stringify(ctx)verbatim at every call site, so for a 10-field schema with three constraints each the sameoperationId/location/schemaNameprefix is repeated 30+ times in the emitted file. Functionally fine, but a follow-up that hoists a per-property const (const _ctx_email = { … }) would shrink output noticeably. -
The
combinedArgsbranching here is correct but a small helper (combineParamsArg(formattedArgs, paramsArg, fn)returning the merged string) would localize thePARAMS_MERGE_INTO_OPTIONS_VALIDATORSspecial-case knowledge and let the.coerce.${fn}(...)and.${fn}(...)returns stay symmetric.
| expect(zod).not.toContain('zodParams('); | ||
| expect(zod).toContain('zod.string().email()'); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Coverage is good for the parser-level injection, but a few realistic shapes aren't exercised:
- No end-to-end test through
generateZodRoute— the new wiring (themakeParamsInjection('body', 'Body')family, the[...preprocess, paramsMutator]aggregation inmutators, the${pascalOperationName}${schemaSuffix}derivation) is all untested. - No reusable-schema test (which would surface the structural gap I flagged on
index.ts:1946). - No
tuple/rest/additionalPropertiestest — onlyarrayandunionexercise structuralfieldPathpropagation. - No
regex/length/multipleOftest — the docs claim these are in scope but onlymin/maxare checked.
wadakatu
left a comment
wadakatu
left a comment
There was a problem hiding this comment.
Thanks for the ping. Overall this fills a real gap — generator-time context (operationId / schemaName / fieldPath) is exactly what Zod's global error map can't disambiguate, the preprocess-style Mutator wiring keeps it consistent, and it's non-breaking when unset. +1 to @z4o4z's reusable-schema point as the thing to resolve before merge. A few smaller notes inline.
| ```ts title="zod-params.ts" | ||
| import { i18n } from './i18n'; | ||
|
|
||
| type ZodParamsContext = { |
There was a problem hiding this comment.
Could this context type be exported from orval instead of hand-written here? Everywhere else orval hands a user function an orval-specific object, the shape ships as an exported type (e.g. override.operationName → OpenApiOperationObject / Verbs via @orval/core). preprocess is the exception only because its signature is plain Zod. Exporting a ZodParamsContext would give users completion + surface breakage when the context evolves, and let this doc import type it instead of duplicating the shape.
| - Applied to base types (`string`, `number`, `boolean`, `bigint`, `date`, `integer`), constraints (`min`, `max`, `gt`, `lt`, `multipleOf`, `regex`, `length`), formats (`email`, `url`, `uuid`, `hostname`, `datetime`, `time`), and `literal`, `enum`, `instanceof`, `stringFormat`. | ||
| - Skipped on modifiers (`optional`, `nullable`, `nullish`, `default`, `describe`) and structural calls (`object`, `array`, `tuple`, `union`, `rest`, `passthrough`, `strict`). | ||
|
|
||
| For static messages, return an object with a string `error`: `return { error: 'My message' }`. The function may return `undefined` to fall back to Zod defaults for a specific call. |
There was a problem hiding this comment.
The { error } shape is zod v4-only. orval supports both v3 and v4 and this injection runs on both paths, but I checked against zod 3.25.76 / 4.3.6: on v3 { error } is silently ignored — no build- or parse-time error, the message just stays the default (.email({ error: 'x' }) → "Invalid email"). { message } works on both. Might be worth a one-liner noting the v3/v4 difference and suggesting { message } for anyone supporting both versions.
There was a problem hiding this comment.
Added a section to the docs to specify this
| * schema name, field path, validator name) and returns a Zod `params` object | ||
| * (e.g. `{ error: ... }`) that is appended as the trailing argument. | ||
| */ | ||
| params?: Mutator; |
There was a problem hiding this comment.
Tiny naming flag (defer to you): generate / coerce / preprocess all key the path-parameter location as param (singular), and this context's location can be 'param' too. The new params (plural) next to them leans on singular-vs-plural to separate two unrelated concepts. Keeping params is defensible since it's Zod's term for the validator's 2nd argument — just flagging in case validatorParams reads cleaner.
There was a problem hiding this comment.
Clarified in the docs as I would like to keep the zod semantics here
594e7e4 to
1251dba
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
packages/orval/src/write-zod-specs.ts (2)
311-326:⚠️ Potential issue | 🟠 Major | ⚡ Quick winInline non-reusable schemas still drop the new params mutator.
Line 321 forwards
paramsMutatoronly through the reusable branch. In the regular inline path,parseZodValidationSchemaDefinition(...)still runs without params context, sooverride.zod.paramssilently does nothing unlessgenerateReusableSchemasis on.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/orval/src/write-zod-specs.ts` around lines 311 - 326, The non-reusable inline path in generateZodSchemasInline is not forwarding the paramsMutator, so override.zod.params is ignored unless generateReusableSchemas is true; fix by passing the paramsMutator into the non-reusable generation flow (the same way generateZodSchemasInlineReusable receives it) and ensure parseZodValidationSchemaDefinition (and any callers that build parameter schemas) are invoked with that paramsMutator/context so override.zod.params is honored for inline schemas as well.
435-453:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe new mutator is gated to reusable-schema mode here.
Lines 445-453 pass
paramsMutatoronly intowriteZodSchemasReusable. When users generate standalone zod schema files withoutgenerateReusableSchemas, the regular branch below still emits validators without the injected params, so the option is only partially implemented.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/orval/src/write-zod-specs.ts` around lines 435 - 453, In writeZodSchemas, the paramsMutator is only forwarded into writeZodSchemasReusable when output.override.zod.generateReusableSchemas is true, leaving the non-reusable path without the injected mutator; forward paramsMutator into the other code path as well (the branch that emits standalone/regular schema validators) so both branches use the mutator, and ensure any helper that generates validators (the same emitter used by writeZodSchemasReusable or the local emission function inside writeZodSchemas) accepts and uses paramsMutator when generating validators.packages/orval/src/write-specs.ts (1)
349-370:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThread
override.zod.paramsinto verb schema files too.Lines 349-370 only wire the new mutator into
writeZodSchemas, but the siblingwriteZodSchemasFromVerbspath still generates*Body/*Params/*Headers/ response schemas without any params injection. That leavesoutput.schemasmode inconsistent with the PR contract of applying params to each generated validator.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/orval/src/write-specs.ts` around lines 349 - 370, The verb-path generation path is missing the params mutator: pass the same schemasParamsMutator used for writeZodSchemas into writeZodSchemasFromVerbs and its implementation so verb-generated validators (*Body/*Params/*Headers/response) also apply override.zod.params; update the call site (where writeZodSchemasFromVerbs is invoked with builder.verbOptions, schemasPath, fileExtension, header, output, {...}) to include schemasParamsMutator, and update the writeZodSchemasFromVerbs signature and any internal uses to accept and invoke the mutator when building schemas from builder.verbOptions and builder.spec so output.schemas mode is consistent with writeZodSchemas.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@packages/orval/src/write-specs.ts`:
- Around line 349-370: The verb-path generation path is missing the params
mutator: pass the same schemasParamsMutator used for writeZodSchemas into
writeZodSchemasFromVerbs and its implementation so verb-generated validators
(*Body/*Params/*Headers/response) also apply override.zod.params; update the
call site (where writeZodSchemasFromVerbs is invoked with builder.verbOptions,
schemasPath, fileExtension, header, output, {...}) to include
schemasParamsMutator, and update the writeZodSchemasFromVerbs signature and any
internal uses to accept and invoke the mutator when building schemas from
builder.verbOptions and builder.spec so output.schemas mode is consistent with
writeZodSchemas.
In `@packages/orval/src/write-zod-specs.ts`:
- Around line 311-326: The non-reusable inline path in generateZodSchemasInline
is not forwarding the paramsMutator, so override.zod.params is ignored unless
generateReusableSchemas is true; fix by passing the paramsMutator into the
non-reusable generation flow (the same way generateZodSchemasInlineReusable
receives it) and ensure parseZodValidationSchemaDefinition (and any callers that
build parameter schemas) are invoked with that paramsMutator/context so
override.zod.params is honored for inline schemas as well.
- Around line 435-453: In writeZodSchemas, the paramsMutator is only forwarded
into writeZodSchemasReusable when output.override.zod.generateReusableSchemas is
true, leaving the non-reusable path without the injected mutator; forward
paramsMutator into the other code path as well (the branch that emits
standalone/regular schema validators) so both branches use the mutator, and
ensure any helper that generates validators (the same emitter used by
writeZodSchemasReusable or the local emission function inside writeZodSchemas)
accepts and uses paramsMutator when generating validators.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e5ed0316-c0e0-4d2e-883b-9fa16982680d
📒 Files selected for processing (10)
docs/content/docs/reference/configuration/output.mdxpackages/core/src/types.tspackages/orval/src/index.tspackages/orval/src/reusable-schemas.test.tspackages/orval/src/reusable-schemas.tspackages/orval/src/utils/options.tspackages/orval/src/write-specs.tspackages/orval/src/write-zod-specs.tspackages/zod/src/index.tspackages/zod/src/zod.test.ts
✅ Files skipped from review due to trivial changes (1)
- docs/content/docs/reference/configuration/output.mdx
🚧 Files skipped from review as they are similar to previous changes (3)
- packages/core/src/types.ts
- packages/orval/src/utils/options.ts
- packages/zod/src/index.ts
1251dba to
dc85d81
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/orval/src/write-zod-specs.ts (1)
612-622: 💤 Low valueMinor: string inclusion check could false-positive on substring matches.
The check
entry.zod.includes(paramsMutator.name)may incorrectly flag the import as needed if the mutator name is a substring of another identifier (e.g., a mutator namedminwould match.min(1)). Since users typically use distinctive names likezodParamsand a false positive only adds an unused import, this is acceptable — but a regex word boundary check (new RegExp(\\b${name}\b`)`) would be more precise if this causes issues.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/orval/src/write-zod-specs.ts` around lines 612 - 622, The current check for whether to include the params mutator import uses a substring test (entry.zod.includes(paramsMutator.name)) which can false-positive on partial matches; update the logic that computes needsParamsImport (used with paramsMutator, paramsMutator.name, entry.zod, and paramsMutatorImport) to test for a whole-word match instead (e.g., build a RegExp with word boundaries around paramsMutator.name and test entry.zod against it) so the import is only emitted when the exact identifier appears.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/orval/src/write-zod-specs.ts`:
- Around line 612-622: The current check for whether to include the params
mutator import uses a substring test (entry.zod.includes(paramsMutator.name))
which can false-positive on partial matches; update the logic that computes
needsParamsImport (used with paramsMutator, paramsMutator.name, entry.zod, and
paramsMutatorImport) to test for a whole-word match instead (e.g., build a
RegExp with word boundaries around paramsMutator.name and test entry.zod against
it) so the import is only emitted when the exact identifier appears.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6e98f46c-078e-4b65-be09-f0fd7669a0b4
📒 Files selected for processing (10)
docs/content/docs/reference/configuration/output.mdxpackages/core/src/types.tspackages/orval/src/index.tspackages/orval/src/reusable-schemas.test.tspackages/orval/src/reusable-schemas.tspackages/orval/src/utils/options.tspackages/orval/src/write-specs.tspackages/orval/src/write-zod-specs.tspackages/zod/src/index.tspackages/zod/src/zod.test.ts
✅ Files skipped from review due to trivial changes (2)
- packages/orval/src/index.ts
- docs/content/docs/reference/configuration/output.mdx
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/core/src/types.ts
- packages/orval/src/utils/options.ts
- packages/orval/src/write-specs.ts
- packages/orval/src/reusable-schemas.test.ts
- packages/orval/src/reusable-schemas.ts
- packages/zod/src/zod.test.ts
dc85d81 to
a6e9a22
Compare
z4o4z
left a comment
z4o4z
left a comment
There was a problem hiding this comment.
Re-review against a6e9a223. The previous round is well-handled — thanks for the thorough follow-up.
Prior comments — all addressed ✅
- The Major one (injection only in
generateZodRoute, missing component schemas) is wired throughreusable-schemas.ts+write-specs.tsfor separate-files mode and covered by two newreusable-schemas.test.tscases. array/tuple/restfieldPathsemantics are now documented inoutput.mdx.- The end-to-end test gap is closed — 11 parser cases plus a real
generateZode2e test. Nice. - Bonus: CodeRabbit's
operationId-vs-operationNameMajor is genuinely fixed (the e2e test asserts the rawcreateCat), andparamsMutatoris now in the returnedmutatorsarray.
One new finding — Major: inline-reusable mode silently skips injection.
The component-schema injection only fires in separate-files mode. In inline-reusable mode it's dead-wired:
shouldGenerateZodSchemasInline(write-specs.ts:288) returnstruefor the common configclient: 'zod'+generateReusableSchemas: truewith nooutput.schemas.- That path calls
generateZodSchemasInline(builder, output, includeZodImport)atwrite-specs.ts:489with no 4th arg, soparamsMutatorisundefinedall the way intogenerateZodSchemasInlineReusable→generateReusableSchemaSet({ paramsMutator: undefined })→ no params on the inlined component schemas. - Net: in inline-reusable mode the operation request/response schemas get
zodParams(...)(viagenerateZodRoute) but the sharedexport const Pet = …definitions they reference do not — whereas separate-files mode injects both. The documented option behaves differently depending on output mode.
Small fix: hoist the schemasParamsMutator resolution out of the isZodSchemas block and pass it at :489:
generateSchemasInline: needZodSchemasInline
? () => generateZodSchemasInline(builder, output, includeZodImport, schemasParamsMutator)
: undefined,Or, if inline-mode injection is intentionally out of scope, drop the dead param + comment and note the limitation in the docs — right now it reads as supported. See the two inline notes.
Recommendation: tests and prior feedback are solid; the inline-reusable gap is the one thing I'd want resolved (or explicitly documented) before merge — it's a real per-mode inconsistency for a mainstream config, and it ships with a comment pointing at a function that doesn't exist.
| const prefix = includeZodImport ? `import { z as zod } from 'zod';\n\n` : ''; | ||
| // The `zodParams` import is registered as a mutator on the operation file | ||
| // (via `generateZodRoute`) and on the standalone single-mode wrapper (via | ||
| // `getInlineZodSchemasMutators`), so the import line is emitted by the |
There was a problem hiding this comment.
This comment references getInlineZodSchemasMutators, but that function doesn't exist anywhere in the repo — so the mechanism it describes ("the import line is emitted by the outer file builder") was never implemented for the inline path.
Concretely: the only caller of generateZodSchemasInline (write-specs.ts:489) passes just 3 args, so paramsMutator is always undefined here in inline-reusable mode. Component schemas inlined via this function therefore get no zodParams(...) injection — even though operations in the same file do (via generateZodRoute). Separate-files mode (writeZodSchemasReusable) injects correctly, so behavior diverges by output mode.
Either wire the mutator through at :489 (hoist schemasParamsMutator so both branches share it) or, if inline injection is out of scope, remove the dead param and this comment and document the limitation.
| builder: WriteZodSchemasInput, | ||
| output: WriteZodOutputOptions, | ||
| includeZodImport = true, | ||
| paramsMutator?: GeneratorMutator, |
There was a problem hiding this comment.
Dead parameter: generateZodSchemasInline's only production caller (write-specs.ts:489) never passes a 4th arg, so paramsMutator is always undefined and the value threaded into generateZodSchemasInlineReusable → generateReusableSchemaSet is too. The plumbing is in place but nothing feeds it. Pass schemasParamsMutator from write-specs.ts to close the inline-reusable gap (see the comment below at line 442).
a6e9a22 to
c92f532
Compare
|
@z4o4z I believe I addressed your concerns |
|
@titivermeesch sorry just merged some stuff and you have 1 merge conflict! |
|
Probably conflicting with my own changes. Looking into it |
c92f532 to
9a1ba2d
Compare
|
@melloware fixed the conflicts |
4 participants
Closes #3425
Adds override.zod.params to inject a Zod params argument (e.g. { error: ... }) into each generated validator. The option takes a Mutator (same shape as the existing preprocess) pointing to a function. Orval calls that function once per validator at schema construction time with codegen-time context (operation, location, schema name, field path, validator name), and emits the return value as the trailing argument of the call.
Summary by CodeRabbit
New Features
Documentation
Tests