chore: upgrade to zod v4#4039
Conversation
🦋 Changeset detectedLatest commit: 4aac7ae The changes in this PR will be included in the next version bump. This PR includes changesets to release 28 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
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:
WalkthroughPackage manifests and overrides update Zod versions, peer ranges, and dependency placement across the workspace. Core and webapp schemas switch to explicit string-keyed records and adjust a few field shapes. Webapp routes and components migrate to 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
carderne
force-pushed
the
chore/zod-4
branch
2 times, most recently
from
ff82d6c to
c60f28b
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| export function getFlagControlType(schema: z.ZodType): FlagControlType { | ||
| // zod v4: schema.def.type is a lowercase tag ("boolean"/"enum"/"number"/...). | ||
| const def = schema.def as { | ||
| type: string; | ||
| checks?: Array<{ _zod?: { def?: { check?: string; value?: number } } }>; | ||
| }; | ||
|
|
||
| if (typeName === "ZodBoolean") { | ||
| if (def.type === "boolean") { | ||
| return { type: "boolean" }; | ||
| } | ||
|
|
||
| if (typeName === "ZodEnum") { | ||
| return { type: "enum", options: schema._def.values as string[] }; | ||
| if (def.type === "enum") { | ||
| return { type: "enum", options: (schema as z.ZodEnum).options as string[] }; | ||
| } | ||
|
|
||
| // z.coerce.number() reports as ZodNumber; pull min/max out of its checks | ||
| // so the UI can render a constrained number input instead of free text. | ||
| if (typeName === "ZodNumber") { | ||
| const checks = (schema._def.checks ?? []) as Array<{ kind: string; value?: number }>; | ||
| const min = checks.find((c) => c.kind === "min")?.value; | ||
| const max = checks.find((c) => c.kind === "max")?.value; | ||
| // z.coerce.number() reports as "number"; pull min/max out of its v4 checks | ||
| // (each check carries `_zod.def.{check,value}`) so the UI can render a | ||
| // constrained number input instead of free text. | ||
| if (def.type === "number") { | ||
| const checks = def.checks ?? []; | ||
| const min = checks.find((c) => c._zod?.def?.check === "greater_than")?._zod?.def?.value; | ||
| const max = checks.find((c) => c._zod?.def?.check === "less_than")?._zod?.def?.value; | ||
| return { type: "number", min, max }; | ||
| } | ||
|
|
There was a problem hiding this comment.
🟡 Admin feature flag toggles render as text inputs instead of checkboxes for most flags
Coerced boolean and number flags are misidentified as strings (getFlagControlType at apps/webapp/app/v3/featureFlags.ts:106) because z.coerce.boolean() in zod v4 wraps the schema in a pipe, so def.type is "pipe" not "boolean", causing the function to fall through to the "string" default.
Impact: The admin feature-flags page shows plain text fields instead of boolean toggles for 9 flags and instead of number inputs for 2 flags.
Mechanism: zod v4 coerce creates a pipe schema
In zod v3, z.coerce.boolean() produced a schema with _def.typeName === "ZodBoolean". In zod v4, z.coerce.boolean() creates a pipe schema (def.type === "pipe") that first coerces the input through Boolean() then validates as boolean. The same applies to z.coerce.number().
The FeatureFlagCatalog at apps/webapp/app/v3/featureFlags.ts:25-35 defines 9 flags with z.coerce.boolean() (e.g., hasQueryAccess, mollifierEnabled) and 2 flags with z.coerce.number() (e.g., computeMigrationFreePercentage). All of these will have def.type === "pipe" in zod v4, so the checks at lines 106 and 117 will never match, and the function returns { type: "string" } for all of them.
The function needs to unwrap pipe schemas to find the inner type, or check for the coerce wrapper specifically.
(Refers to lines 99-124)
Prompt for agents
The getFlagControlType function in apps/webapp/app/v3/featureFlags.ts needs to handle zod v4 pipe schemas (created by z.coerce.boolean(), z.coerce.number(), etc.). In zod v4, coerced schemas wrap the inner schema in a pipe, so def.type is 'pipe' rather than the inner type like 'boolean' or 'number'. The function should unwrap pipe schemas to find the inner type. For example, check if def.type is 'pipe' and if so, look at the destination/output schema's def.type instead. Similarly, the checks array for min/max on number schemas may be structured differently in zod v4 pipes — the checks live on the inner number schema, not the outer pipe.
Was this helpful? React with 👍 or 👎 to provide feedback.
| navigation.formAction === "/resources/feedback" && | ||
| navigation.state === "loading" && | ||
| Object.keys(form.allErrors).length === 0 | ||
| (form.errors === undefined || form.errors.length === 0) |
There was a problem hiding this comment.
🚩 Feedback dialog close condition changed from allErrors to form.errors
At apps/webapp/app/components/Feedback.tsx:56, the condition changed from Object.keys(form.allErrors).length === 0 to (form.errors === undefined || form.errors.length === 0). In conform v1 (used with @conform-to/zod), form.allErrors was an object mapping field names to error arrays. In the newer conform API used with @conform-to/zod/v4, form.errors is a flat string array of form-level errors. This means the new check only looks at form-level errors, not field-level errors. If a field has a validation error but the form itself doesn't, the dialog would close prematurely. However, this may be intentional — the dialog submits to a server action, and field errors would prevent successful submission, so the navigation.state === "loading" check (indicating the server accepted the form) may be sufficient to gate the close.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Zod v4 compatibility
Upgrades the monorepo's internal zod version from 3.x to 4.4.3 and widens the peer
dependency on all published packages to
"^3.25.0 || ^4.0.0".For library consumers
No breaking change if you are on zod 3.25+. The peer dependency range is widened, not
narrowed — your existing zod 3.25+ install continues to satisfy it and the library code
is runtime-compatible with both versions. Zod 4.x is now also supported. Bumped as minor
across all affected packages.
Minimum zod 3 version is 3.25.0 (not 3.0.0).
API compatibility
Zod types appear in the public API of
@trigger.dev/coreand@trigger.dev/redis-worker(generic constraints like
T extends z.ZodTypeAny, exported schema values typed asz.ZodType<T>, andWorkerCatalog's schema field). These types exist in both zod 3 andzod 4, so TypeScript consumers on either version should resolve them without errors —
the shapes are structurally compatible across versions.
If you pass your own zod schemas into library APIs (e.g.
zodfetch,zodShapeStream,WorkerCatalog), schemas from zod 3.25+ and zod 4.x are both accepted.WorkerCatalogusesz.ZodFirstPartySchemaTypes, which is present in zod 4 via acompatibility alias but marked
@deprecated. This is intentional — the type is stillfully functional, and we've left it in place to avoid a breaking API change.
TODO list before merging