Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
dosubot
Bot
added
the
size:L
WalkthroughThis update standardizes Zod imports across the codebase, switching from named imports ( Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant Zod
participant JSON_SCHEMA_REGISTRY
participant ZodToJsonSchemaConverter
Developer->>Zod: import * as z from 'zod'
Developer->>Zod: Define schemas (z.object, z.file, z.url, z.email, etc.)
Developer->>JSON_SCHEMA_REGISTRY: add(schema, {examples})
Developer->>ZodToJsonSchemaConverter: import experimental version
ZodToJsonSchemaConverter->>Zod: Convert schemas to JSON Schema
Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @unnoq, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces comprehensive support for Zod v4 throughout the project. It involves upgrading the Zod dependency, adapting the codebase to Zod v4's new API, and enhancing the OpenAPI integration to leverage Zod v4's capabilities for schema generation and example handling. The changes ensure compatibility with the latest Zod version while modernizing the validation and schema definition practices across the monorepo.
Highlights
- Zod v4 Upgrade: The core change is the upgrade of the Zod dependency to version 4 across the entire monorepo, ensuring compatibility with the latest Zod features and improvements.
- API Modernization: The codebase has been updated to leverage Zod v4's new API, including namespace imports (
import * as z from 'zod'), new top-level utility functions (z.prettifyError,z.flattenError), and dedicated schema types (z.uuid(),z.email(),z.file(),z.url()). This replaces older patterns likez.string().uuid()orz.instanceof(File). - Enhanced OpenAPI Integration: The
@orpc/zodpackage now utilizesexperimental_ZodToJsonSchemaConverterandexperimental_JSON_SCHEMA_REGISTRYto provide robust OpenAPI schema generation and example registration specifically for Zod v4 schemas, replacing the previousoz.openapimethods. - Internal Zod Package Refinement: The
@orpc/zodpackage has been refactored to align with Zod v4's internal changes, including a migration from the externalzod-to-json-schemalibrary to an internal conversion logic, and adjusting internal type imports tozod/v3where necessary for compatibility. - Documentation and Playground Alignment: All relevant documentation and playground examples have been updated to reflect the Zod v4 API changes and best practices, ensuring consistency and ease of use for developers.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/experimental-durable-event-iterator
@orpc/hey-api
@orpc/json-schema
@orpc/nest
@orpc/openapi
@orpc/openapi-client
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-aws-lambda
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/standard-server-peer
@orpc/svelte-query
@orpc/tanstack-query
@orpc/trpc
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
There was a problem hiding this comment.
Code Review
This pull request introduces comprehensive support for Zod v4. The changes are extensive, touching documentation, tests, package dependencies, and implementation files across the repository to adopt the new Zod v4 APIs and conventions. I've identified a critical issue with the peerDependencies version for zod in packages/zod/package.json, and a potential bug in one of the playground examples where number coercion was removed, which could lead to runtime errors. Addressing these points will help ensure the quality and correctness of the release.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🔭 Outside diff range comments (2)
packages/zod/src/converter.components.test.ts (1)
1-11: Getter inside the Zod shape causes a TDZ / self-reference riskconst User = z.object({ … get parents(): any { // getter executes immediately return z.array(User).optional() }, })When
z.objectenumerates the shape, it invokes the getter, butUseris still in its temporal-dead-zone, so at runtime this throws aReferenceError.
Use az.lazyinstead:- get parents(): any { - return z.array(User).optional() - }, + parents: z.lazy(() => z.array(User)).optional(),This avoids the TDZ and is clearer for Zod tooling.
packages/zod/package.json (1)
45-56: TightenpeerDependencies.zodto v4-only supportYour package imports exclusively from
zod/v3, which only exists in Zod v4’s compatibility layer. Allowing consumers to install Zod 3.x (via>=3.25.0) will lead toERR_MODULE_NOT_FOUNDat runtime.Please update
packages/zod/package.jsonaccordingly:"peerDependencies": { - "zod": ">=3.25.0" + "zod": "^4.0.0" },After making this change, verify that your CI still passes (with your existing devDependency on
zod@^4.0.5).
♻️ Duplicate comments (5)
packages/zod/src/custom-json-schema.test-d.ts (1)
1-1: Same import issue as aboveSee earlier note about the
zod/v3sub-path & switch to namespace import.packages/zod/src/coercer.test.ts (1)
1-2: Repeat of the /v3 import concernPlease address the same resolution & style issues noted in the first comment.
playgrounds/contract-first/src/schemas/auth.ts (1)
4-4: Consistent email validation pattern across playgrounds.The change from
z.string().email()toz.email()is consistent with similar updates in other playground files (nuxt, solid-start, svelte-kit). This pattern suggests it's a valid Zod v4 feature, but verification of the syntax is still recommended.playgrounds/browser-extension/entrypoints/background/schemas/auth.ts (1)
4-4: Same verification needed as in electron auth schema.This uses the same
z.email()pattern that needs verification for Zod v4 compatibility.playgrounds/nest/src/schemas/auth.ts (1)
4-4: Consistent with other auth schemas.This follows the same pattern as the other auth schema files. The
z.email()usage still needs the same verification mentioned in other files.
🧹 Nitpick comments (7)
apps/content/package.json (1)
41-42: Add"zod": "^4.0.5"– OK, but consider workspace protocol for consistency.Most internal packages use workspace refs (
"workspace:*") for first-party deps, but external libs likezodare pinned. If you later symlinkzodvia the workspace, switching to"workspace:^4.0.5"will avoid duplicate installs.packages/client/package.json (1)
73-74: Potential peer dependency leakThe client package often ships validators that execute in the browser. Treating
zodas a pure dev dependency risks bundlers tree-shaking it out. Consider either:
- Move to
"dependencies", or- Declare
"peerDependencies": { "zod": ">=4" }to enforce that host applications install a compatible copy.playgrounds/electron/package.json (1)
34-38: Electron bundle size watch-outZod v4’s ESM build is ~30 % larger than v3. For the Electron preload & renderer bundles this can inflate startup time. If size becomes an issue, consider enabling
esbuild ‑-drop:debuggeror ship a customtreeshakeconfig.packages/client/tests/helpers.ts (1)
5-5: Namespace import: good, but remember tree-shakingSwitching to a single
* as zimport is fine, but note that bundlers like ESBuild/Rollup cannot treeshake unused Zod sub-schemas from a namespace import. In test code this is negligible, but in production helpers consider:import { object, string, number, file } from 'zod'to keep bundle size small.
packages/zod/README.md (1)
89-89: Consider documenting the experimental nature of the converter.While the migration to
experimental_ZodToJsonSchemaConverteris consistent with the codebase changes, consider adding a note in the documentation that this is an experimental API for Zod v4 to set proper user expectations.playgrounds/electron/tsconfig.json (1)
14-16: Consider the implications of disabling strict TypeScript checks.Disabling
noImplicitReturns,noUnusedLocals, andnoUnusedParametersreduces type safety and code quality enforcement. These were likely disabled to accommodate existing code, but consider re-enabling them incrementally.- "noImplicitReturns": false, - "noUnusedLocals": false, - "noUnusedParameters": false, + "noImplicitReturns": true, + "noUnusedLocals": true, + "noUnusedParameters": true,packages/zod/src/converter.test.ts (1)
383-383: Update test description to match actual class name.The test description references
zodToJsonSchemaConverter.convertbut should referenceZodToJsonSchemaConverter.convertto match the actual class name.-])('zodToJsonSchemaConverter.convert %#', ({ schema, input, output = input }) => { +])('ZodToJsonSchemaConverter.convert %#', ({ schema, input, output = input }) => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (107)
README.md(2 hunks)apps/content/docs/advanced/validation-errors.md(8 hunks)apps/content/docs/client/error-handling.md(1 hunks)apps/content/docs/client/event-iterator.md(1 hunks)apps/content/docs/client/server-side.md(4 hunks)apps/content/docs/contract-first/define-contract.md(2 hunks)apps/content/docs/error-handling.md(1 hunks)apps/content/docs/file-upload-download.md(1 hunks)apps/content/docs/getting-started.md(1 hunks)apps/content/docs/openapi/getting-started.md(2 hunks)apps/content/docs/openapi/integrations/implement-contract-in-nest.md(1 hunks)apps/content/docs/openapi/openapi-specification.md(4 hunks)apps/content/docs/openapi/plugins/openapi-reference.md(1 hunks)apps/content/docs/plugins/hibernation.md(1 hunks)apps/content/docs/server-action.md(3 hunks)apps/content/examples/openai-streaming.md(1 hunks)apps/content/package.json(1 hunks)apps/content/shared/planet.ts(1 hunks)packages/arktype/src/converter.test.ts(1 hunks)packages/client/package.json(1 hunks)packages/client/tests/helpers.ts(2 hunks)packages/contract/package.json(1 hunks)packages/contract/src/event-iterator.test.ts(1 hunks)packages/contract/src/schema-utils.test.ts(1 hunks)packages/contract/src/schema.test-d.ts(1 hunks)packages/contract/tests/helpers.ts(1 hunks)packages/contract/tests/shared.ts(1 hunks)packages/json-schema/package.json(1 hunks)packages/json-schema/src/smart-coercion-plugin.test.ts(1 hunks)packages/nest/package.json(1 hunks)packages/nest/src/implement.test.ts(1 hunks)packages/openapi/package.json(1 hunks)packages/openapi/src/openapi-generator.test.ts(1 hunks)packages/openapi/src/plugins/openapi-reference.test.ts(1 hunks)packages/openapi/src/schema-converter.test.ts(1 hunks)packages/react-query/package.json(1 hunks)packages/react/package.json(1 hunks)packages/react/src/action-form.test.ts(1 hunks)packages/react/src/hooks/server-action.test-d.ts(1 hunks)packages/server/README.md(1 hunks)packages/server/src/builder.test-d.ts(1 hunks)packages/server/src/builder.test.ts(1 hunks)packages/server/src/error.test.ts(1 hunks)packages/server/src/procedure-client.test.ts(1 hunks)packages/server/src/procedure-decorated.test.ts(1 hunks)packages/server/src/procedure-utils.test.ts(1 hunks)packages/shared/package.json(1 hunks)packages/solid-query/package.json(1 hunks)packages/svelte-query/package.json(1 hunks)packages/tanstack-query/package.json(1 hunks)packages/trpc/package.json(1 hunks)packages/trpc/src/to-orpc-router.test.ts(1 hunks)packages/valibot/src/converter.test.ts(1 hunks)packages/zod/README.md(3 hunks)packages/zod/package.json(2 hunks)packages/zod/src/coercer.test.ts(1 hunks)packages/zod/src/coercer.ts(1 hunks)packages/zod/src/converter.components.test.ts(1 hunks)packages/zod/src/converter.test.ts(2 hunks)packages/zod/src/converter.ts(1 hunks)packages/zod/src/custom-json-schema.test-d.ts(1 hunks)packages/zod/src/custom-json-schema.test.ts(1 hunks)packages/zod/src/custom-json-schema.ts(1 hunks)packages/zod/src/schemas/base.ts(1 hunks)packages/zod/src/schemas/blob.ts(1 hunks)packages/zod/src/schemas/file.ts(1 hunks)packages/zod/src/schemas/regexp.ts(1 hunks)packages/zod/src/schemas/url.ts(1 hunks)playgrounds/astro/package.json(1 hunks)playgrounds/astro/src/pages/api/[...rest].ts(1 hunks)playgrounds/astro/src/router/planet.ts(1 hunks)playgrounds/astro/src/router/sse.ts(1 hunks)playgrounds/astro/src/schemas/auth.ts(1 hunks)playgrounds/astro/src/schemas/planet.ts(2 hunks)playgrounds/astro/src/schemas/user.ts(1 hunks)playgrounds/browser-extension/entrypoints/background/router/planet.ts(1 hunks)playgrounds/browser-extension/entrypoints/background/router/sse.ts(1 hunks)playgrounds/browser-extension/entrypoints/background/schemas/auth.ts(1 hunks)playgrounds/browser-extension/entrypoints/background/schemas/planet.ts(2 hunks)playgrounds/browser-extension/entrypoints/background/schemas/user.ts(1 hunks)playgrounds/browser-extension/package.json(1 hunks)playgrounds/cloudflare-worker/package.json(1 hunks)playgrounds/cloudflare-worker/worker/dos/chat-room.ts(1 hunks)playgrounds/contract-first/package.json(1 hunks)playgrounds/contract-first/src/contract/planet.ts(1 hunks)playgrounds/contract-first/src/contract/sse.ts(1 hunks)playgrounds/contract-first/src/main.ts(1 hunks)playgrounds/contract-first/src/schemas/auth.ts(1 hunks)playgrounds/contract-first/src/schemas/planet.ts(2 hunks)playgrounds/contract-first/src/schemas/user.ts(1 hunks)playgrounds/electron/package.json(1 hunks)playgrounds/electron/src/main/router/planet.ts(1 hunks)playgrounds/electron/src/main/router/sse.ts(1 hunks)playgrounds/electron/src/main/schemas/auth.ts(1 hunks)playgrounds/electron/src/main/schemas/planet.ts(2 hunks)playgrounds/electron/src/main/schemas/user.ts(1 hunks)playgrounds/electron/tsconfig.json(1 hunks)playgrounds/electron/tsconfig.web.json(0 hunks)playgrounds/nest/package.json(1 hunks)playgrounds/nest/src/contract/planet.ts(1 hunks)playgrounds/nest/src/contract/sse.ts(1 hunks)playgrounds/nest/src/reference/reference.service.ts(1 hunks)playgrounds/nest/src/schemas/auth.ts(1 hunks)playgrounds/nest/src/schemas/planet.ts(2 hunks)playgrounds/nest/src/schemas/user.ts(1 hunks)playgrounds/nest/tsconfig.json(1 hunks)playgrounds/next/package.json(1 hunks)
⛔ Files not processed due to max files limit (35)
- playgrounds/next/src/app/actions.ts
- playgrounds/next/src/app/api/[[...rest]]/route.ts
- playgrounds/next/src/router/planet.ts
- playgrounds/next/src/router/sse.ts
- playgrounds/next/src/schemas/auth.ts
- playgrounds/next/src/schemas/planet.ts
- playgrounds/next/src/schemas/user.ts
- playgrounds/nuxt/package.json
- playgrounds/nuxt/server/router/planet.ts
- playgrounds/nuxt/server/router/sse.ts
- playgrounds/nuxt/server/routes/api/[...].ts
- playgrounds/nuxt/server/schemas/auth.ts
- playgrounds/nuxt/server/schemas/planet.ts
- playgrounds/nuxt/server/schemas/user.ts
- playgrounds/solid-start/package.json
- playgrounds/solid-start/src/router/planet.ts
- playgrounds/solid-start/src/router/sse.ts
- playgrounds/solid-start/src/routes/api/[...rest].ts
- playgrounds/solid-start/src/schemas/auth.ts
- playgrounds/solid-start/src/schemas/planet.ts
- playgrounds/solid-start/src/schemas/user.ts
- playgrounds/svelte-kit/package.json
- playgrounds/svelte-kit/src/router/planet.ts
- playgrounds/svelte-kit/src/router/sse.ts
- playgrounds/svelte-kit/src/routes/api/[...rest]/+server.ts
- playgrounds/svelte-kit/src/schemas/auth.ts
- playgrounds/svelte-kit/src/schemas/planet.ts
- playgrounds/svelte-kit/src/schemas/user.ts
- playgrounds/tanstack-start/package.json
- playgrounds/tanstack-start/src/router/planet.ts
- playgrounds/tanstack-start/src/router/sse.ts
- playgrounds/tanstack-start/src/routes/api/$.ts
- playgrounds/tanstack-start/src/schemas/auth.ts
- playgrounds/tanstack-start/src/schemas/planet.ts
- playgrounds/tanstack-start/src/schemas/user.ts
💤 Files with no reviewable changes (1)
- playgrounds/electron/tsconfig.web.json
🧰 Additional context used
🧬 Code Graph Analysis (9)
playgrounds/electron/src/main/schemas/auth.ts (1)
playgrounds/browser-extension/entrypoints/background/schemas/auth.ts (1)
CredentialSchema(3-6)
playgrounds/browser-extension/entrypoints/background/schemas/auth.ts (1)
playgrounds/electron/src/main/schemas/auth.ts (1)
CredentialSchema(3-6)
playgrounds/contract-first/src/schemas/auth.ts (3)
playgrounds/nuxt/server/schemas/auth.ts (1)
CredentialSchema(3-6)playgrounds/solid-start/src/schemas/auth.ts (1)
CredentialSchema(3-6)playgrounds/svelte-kit/src/schemas/auth.ts (1)
CredentialSchema(3-6)
playgrounds/browser-extension/entrypoints/background/schemas/planet.ts (1)
playgrounds/electron/src/main/schemas/planet.ts (2)
UpdatePlanetSchema(14-19)PlanetSchema(21-27)
playgrounds/electron/src/main/schemas/planet.ts (1)
playgrounds/browser-extension/entrypoints/background/schemas/planet.ts (2)
UpdatePlanetSchema(14-19)PlanetSchema(21-27)
playgrounds/browser-extension/entrypoints/background/schemas/user.ts (1)
playgrounds/electron/src/main/schemas/user.ts (4)
NewUser(4-4)NewUserSchema(7-11)User(5-5)UserSchema(23-27)
playgrounds/contract-first/src/schemas/user.ts (3)
playgrounds/nuxt/server/schemas/user.ts (4)
NewUser(4-4)NewUserSchema(7-11)User(5-5)UserSchema(23-27)playgrounds/svelte-kit/src/schemas/user.ts (4)
NewUser(4-4)NewUserSchema(7-11)User(5-5)UserSchema(23-27)playgrounds/solid-start/src/schemas/user.ts (4)
NewUser(4-4)NewUserSchema(7-11)User(5-5)UserSchema(23-27)
playgrounds/electron/src/main/schemas/user.ts (1)
playgrounds/browser-extension/entrypoints/background/schemas/user.ts (4)
NewUser(4-4)NewUserSchema(7-11)User(5-5)UserSchema(23-27)
playgrounds/contract-first/src/schemas/planet.ts (3)
playgrounds/nuxt/server/schemas/planet.ts (2)
UpdatePlanetSchema(14-19)PlanetSchema(21-27)playgrounds/solid-start/src/schemas/planet.ts (2)
UpdatePlanetSchema(14-19)PlanetSchema(21-27)playgrounds/svelte-kit/src/schemas/planet.ts (2)
UpdatePlanetSchema(14-19)PlanetSchema(21-27)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: publish-commit
- GitHub Check: lint
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (107)
playgrounds/nest/tsconfig.json (1)
17-17: Playground declarations aren’t consumed—keeping"declaration": falseis safe
We’ve verified:
- No
package.json“types” fields referenceplaygrounds/nest/dist.- No other
tsconfig.jsonextendsplaygrounds/nest/tsconfig.json.- This folder is example-only and not published as a library.
You can leave
"declaration": falseenabled to speed up builds without impacting downstream consumers.packages/svelte-query/package.json (1)
50-50: Version bump without matching path aliases
devDependencies.zod→^4.0.5, yet several packages now import from'zod/v3'.
If/v3is not exported byzod@4, local unit tests will pass (because they run inside the monorepo with path mappings) but published consumers will break.Ensure that:
•/v3is covered by aexportssub-path in every publishedpackage.json, or
• All internal code switches to the canonicalzodentry-point.packages/trpc/package.json (1)
45-48: Confirm zod@^4.0.5 availability and devDependency placementzod@^4.0.5 is published under the “latest” dist-tag, and our search shows only test files import it (no runtime imports in packages/trpc/src). Keeping zod in devDependencies is correct.
playgrounds/contract-first/package.json (1)
21-24: Zod v4.0.5 is available on npm
Confirmed withnpm view zod@4.0.5 versionreturning4.0.5. Safe to merge.packages/react/package.json (1)
54-57: DevDependency Scope Confirmed – No Zod Runtime Imports in @orpc/reactA grep over
packages/react/src(excluding all test files) returned zerozodimports. There’s no runtime reference to Zod in the published code, so it’s only used for development/testing. Keeping Zod underdevDependenciesis correct.packages/shared/package.json (1)
40-44: All Zod imports are in test files — devDependency is correct
The only occurrence of Zod inpackages/shared/srcis inobject.test.ts, so there’s no runtime usage. Keeping Zod indevDependenciesis appropriate.packages/react-query/package.json (1)
49-52: Check the ripple effect of the Zod v4 upgrade.Upgrading to a new major of Zod is breaking. Although it appears only in
devDependencieshere, several workspace packages list Zod as a peer / direct dependency. Please verify:
- No package still pins
^3.*.- Generated typings / runtime code that rely on legacy enums (
z.enum) or.nonstrict()APIs compile and pass tests under v4.- Lock-file is re-hoisted so that only one Zod version is installed (avoids duplicate bundles for consumers).
A quick smoke-test can prevent downstream build failures.
playgrounds/electron/src/main/router/sse.ts (1)
2-2: Import style LGTM.The switch to namespace import (
* as z) matches the new project guideline and keeps intellisense intact.playgrounds/nest/src/contract/planet.ts (1)
1-1: Consistent Zod import adopted.Nothing else changed; contract typings remain unaffected.
packages/react/src/hooks/server-action.test-d.ts (1)
3-3: Import update acknowledged.Type-level tests still compile; no further action needed.
playgrounds/cloudflare-worker/worker/dos/chat-room.ts (1)
3-3: Namespace import looks good.No functional differences introduced.
packages/zod/src/schemas/base.ts (1)
1-1: Importing from the v3 sub-path is OK, but be mindful of mixed runtimes
zod/v3is exposed by Zod v4 purely for backwards-compatibility. Relying on v3 types while the rest of the repo runs v4 at runtime can easily lead to subtle mismatches (e.g._defstructure changes across majors). Make sure:
- There is no runtime call site that mixes v3 objects with v4 ones.
- Your bundler / tsconfig is set to resolve the
zod/v3export condition (Node ≥ 18 or an ESM-aware bundler).If both points are covered, the change looks fine.
playgrounds/astro/package.json (1)
29-29: Double-check that every workspace depends on the same Zod major
"zod": "^4.0.5"is added here, but several packages still import fromzod/v3. Yarn/PNPM will hoist only one copy of Zod; if any workspace accidentally keeps a caret-range of^3, you will get duplicate copies or peer-dep warnings.Search the repo for
\"zod\": \"^3to avoid version skew.packages/zod/src/schemas/regexp.ts (1)
1-3:customimport aligns with v3 API – good catch
zod/v3still exposescustom, which was removed in v4, so the switch keeps the helper working without code changes.playgrounds/astro/src/router/sse.ts (1)
2-2: Import style change is correct and consistent with the v4 migration.Nothing else to flag here.
packages/contract/src/schema-utils.test.ts (1)
3-3: Namespace import switch LGTM.The test file now aligns with the unified import pattern.
packages/server/src/builder.test.ts (1)
3-3: Import updated successfully.No functional impact; existing usages (
z.void(), etc.) remain valid under Zod v4.packages/nest/package.json (1)
74-74: Version bump to Zod v4 acknowledged.Ensure any Nest-specific pipes or filters that relied on v3 behaviour have corresponding updates/tests.
packages/openapi/package.json (1)
77-78: Double-check whetherzodis required at runtimeIf any helpers in
@orpc/openapitransform Zod schemas dynamically (e.g.zod → openapiconversion on the server) thenzodmust live in"dependencies", not"devDependencies".
Please audit the package imports and adjust to avoid runtimeMODULE_NOT_FOUNDin consumer projects.packages/json-schema/package.json (1)
44-45: Align dependency type with actual usageThe JSON-schema adapter primarily converts Zod schemas during build time; if that assumption is correct, keeping
zodindevDependenciesis fine. Otherwise shift it to runtime as in previous comments.packages/zod/src/schemas/url.ts (1)
1-4: No change needed: ‘zod/v3’ imports are intentional for v3 compatibilityThe repository is designed to support both Zod v3 and v4:
• In packages/zod/package.json, “zod” is a peer dependency (>= 3.25.0) and the default entrypoint (exports “.”) targets v3 via
zod/v3.
• A separate “./zod4” entrypoint exists for consumers using Zod v4.All of the schema files under packages/zod/src import from
zod/v3by design to maintain v3 compatibility. Switching them to a namespace import fromzodwould break the v3 stub and defeat the dual‐entrypoint strategy.No modifications are required here.
Likely an incorrect or invalid review comment.
playgrounds/cloudflare-worker/package.json (1)
24-28: Double-check v4 runtime compatibility of Zod in the Worker environmentJumping from the latest v3 line to
^4.0.5is a major change that may introduce breaking API shifts (e.g., refined error maps, changed.parseAsyncbehaviour). Cloudflare Workers run on a restricted V8 isolate; ensure any optional Node-specific polyfills added by Zod v4 are not pulled in, and that all Worker-side schema parsing remains green (unit + e2e).If everything is green, no further action required.
playgrounds/next/package.json (1)
26-30: Confirm Next.js migration guides for Zod v4 validation middlewareNext.js examples frequently rely on
z.object({})for route handlers / tRPC procedures. Verify that all playground API routes were bumped to the new namespace-import style and that any removed v3 helpers (z.string().email() → z.email()) were updated; otherwise the dev server will crash on first request.playgrounds/browser-extension/entrypoints/background/router/sse.ts (1)
2-2: LGTM – import style now matches the repo-wide conventionThe namespace import avoids tree-shaking pitfalls seen with
import { z }, and no other changes were introduced.packages/zod/src/coercer.ts (1)
26-28: No action needed:zod/v3sub-path is officially exported in Zod v4.0.5The
npm view zod@4.0.5 exportsoutput confirms that./v3is exposed:{ "types": "./v3/index.d.cts", "import": "./v3/index.js", "require": "./v3/index.cjs", "@zod/source": "./src/v3/index.ts" }Therefore the import in
packages/zod/src/coercer.tscan remain:} from 'zod/v3' import { guard, isObject } from '@orpc/shared' import { ZodFirstPartyTypeKind } from 'zod/v3'packages/solid-query/package.json (1)
50-51:zodbumped to ^4.0.5 only in devDependencies – check transitive runtime usageIf any compiled files inside
@orpc/solid-queryperform a runtimerequire('zod'), consumers will needzodas a peer dependency, not just dev. Please audit the source; if the import is purely type-level, leave as-is, otherwise promote topeerDependencies.playgrounds/browser-extension/package.json (1)
32-33: Mirror dependency strategy with playground bundlersThe playground ships bundled output, so
zodsitting indevDependenciesis usually fine. Just double-check that Vite/WXT doesn’t externalisezod(in which case it must be a prod dependency).apps/content/examples/openai-streaming.md (1)
16-17: Nice switch to namespace import
import * as z from 'zod'keeps tree-shaking intact and matches the new repo-wide convention. 👍apps/content/docs/client/event-iterator.md (1)
15-15: LGTM! Import style updated for Zod v4 compatibility.The change from named import to namespace import aligns with the PR objective and maintains consistent usage throughout the documentation.
packages/contract/tests/helpers.ts (1)
1-1: LGTM! Zod import standardized for v4 compatibility.The namespace import change is consistent with the codebase-wide update and maintains all existing functionality.
packages/valibot/src/converter.test.ts (1)
2-2: LGTM! Import updated for consistency across the codebase.The namespace import change aligns with the Zod v4 migration and maintains all test functionality.
playgrounds/electron/src/main/router/planet.ts (1)
2-2: LGTM! Zod import updated for v4 compatibility.The namespace import change is consistent with the codebase-wide migration and preserves all router functionality.
apps/content/docs/openapi/integrations/implement-contract-in-nest.md (1)
73-73: LGTM! Documentation example updated for Zod v4 compatibility.The namespace import change ensures documentation examples align with the new codebase standard while maintaining all functionality.
apps/content/docs/error-handling.md (1)
55-55: Import style update reads wellDoc snippet now mirrors the new namespace-import convention adopted across the codebase. Nothing else to flag.
apps/content/shared/planet.ts (1)
1-1: Confirm compiler settings for namespace import
import * as z from 'zod'relies on your TS module-resolution settings (e.g.esModuleInterop: false,module: ESNext). Just double-check that downstream builds/tests still resolvez.object()correctly—especially if any consumers compile withallowSyntheticDefaultImports.packages/openapi/src/openapi-generator.test.ts (1)
3-3: LGTM – test updated to new import formNo behavioural changes introduced; test continues to use the same
zAPI surface.apps/content/docs/plugins/hibernation.md (1)
80-80: Docs aligned with import conventionNamespace import renders fine in the MDX snippet.
packages/server/src/procedure-utils.test.ts (1)
2-2: Import change acknowledgedUnit test compiles against the updated namespace import without side effects.
packages/server/README.md (1)
69-69: LGTM! Documentation updated to reflect new import standard.The namespace import pattern aligns with the Zod v4 migration effort and improves consistency across the codebase documentation.
packages/server/src/procedure-decorated.test.ts (1)
1-1: Import standardization looks good.The namespace import maintains compatibility while aligning with the project's Zod v4 migration strategy.
packages/arktype/src/converter.test.ts (1)
2-2: Consistent import standardization.The namespace import maintains test functionality while following the project's new Zod import pattern.
packages/contract/src/schema.test-d.ts (1)
4-4: Type definition test import updated correctly.The namespace import maintains TypeScript type inference behavior while standardizing the import pattern.
playgrounds/browser-extension/entrypoints/background/router/planet.ts (1)
2-2: Application code import standardized successfully.The namespace import maintains full functionality while aligning with the Zod v4 migration strategy across the codebase.
packages/json-schema/src/smart-coercion-plugin.test.ts (1)
1-1: Consistent namespace import aligns with Zod v4Switching to
import * as z from 'zod'avoids the fragile named-export ({ z }) pattern and works seamlessly with both CJS/ESM bundles in v4. Looks good.packages/openapi/src/schema-converter.test.ts (1)
1-1: Unified Zod import styleThe namespace import keeps the test in sync with the project-wide v4 migration and prevents future type-check hiccups.
packages/contract/src/event-iterator.test.ts (1)
3-3: Namespace import is the correct choice for v4Nothing else changes in the file; the new import builds fine and improves compatibility.
packages/react/src/action-form.test.ts (1)
2-2: Import updated for v4 compatibilityThe namespace form is consistent and safe; no further action needed.
packages/server/src/procedure-client.test.ts (1)
2-2: Good move toimport * as zKeeps the large test suite aligned with Zod v4—LGTM.
packages/trpc/src/to-orpc-router.test.ts (1)
4-4: Namespace import aligns with new convention – looks good.
The switch toimport * as z from 'zod'keeps the test in-sync with the project-wide v4 migration and compiles fine under both TSesModuleInteropsettings.playgrounds/astro/src/router/planet.ts (1)
2-2: Import style updated correctly.
No further action needed – all downstream references (z.object,z.number, …) remain valid.packages/zod/src/converter.ts (1)
34-40: Verify that thezod/v3sub-path resolves at runtime.
ZodFirstPartyTypeKindis used at runtime (switch statement), so bundlers / Node must be able torequire('zod/v3'). This sub-path is available in recent Zod 4.x, but fails on 3.x and on older tooling that doesn’t honor theexportsmap.If compatibility with both Zod 3 and 4 is expected, consider one of:
-import { ZodFirstPartyTypeKind } from 'zod/v3' +import { ZodFirstPartyTypeKind } from 'zod' // always present at runtimeor a defensive dynamic import fallback.
Please run the project with the intended Zod version and make sure the module resolution does not break when published.
packages/openapi/src/plugins/openapi-reference.test.ts (1)
2-2: Consistent namespace import – OK.
Matches the rest of the codebase; no issues spotted.packages/contract/tests/shared.ts (1)
3-3: Import change acknowledged.
The file compiles and behaves the same; nothing else to flag.playgrounds/contract-first/src/contract/sse.ts (1)
2-2: Consistent namespace import looks good.The switch to
import * as z from 'zod'matches the new v4-style across the codebase and keeps all subsequentz.references intact. No further action needed.playgrounds/contract-first/src/contract/planet.ts (1)
1-1: Import update acknowledged.Namespace import aligns with the repo-wide convention and doesn’t affect the existing logic. ✅
apps/content/docs/client/error-handling.md (1)
14-14: Doc snippet updated correctly.The example now mirrors the code changes in src files, avoiding confusion for readers. Looks good.
packages/nest/src/implement.test.ts (1)
10-10: Test import switched to namespace – OK.All usages of
zremain valid; no other side-effects in the test suite. 👍apps/content/docs/openapi/plugins/openapi-reference.md (1)
17-19: Converter import change makes sense.Re-exporting the experimental converter under the old name maintains example clarity while pointing to the v4 module. No issues spotted.
packages/server/src/builder.test-d.ts (1)
14-14: LGTM – import style switch onlyThe change is purely cosmetic and aligns the test with the new namespace-import convention. No further action required.
apps/content/docs/contract-first/define-contract.md (1)
43-44: Docs compile snippets but drop type-only import – watch for Docusaurus/TS PlaygroundBoth code blocks swap to
import * as z from 'zod', which is correct for runtime.
If the docs playground previously relied on// @filename: index.tsstyle compilation, make sure the TypeScript service still resolves theesModuleInteroprequirement (allowSyntheticDefaultImports=falsescenario), otherwise the rendered playground will throw.No code change needed, just flagging for the docs build step.
Also applies to: 81-82
packages/server/src/error.test.ts (1)
3-3: Import style updated – no functional impactChange aligns with project-wide convention. Tests remain intact.
apps/content/docs/getting-started.md (1)
53-53: LGTM: Documentation updated to reflect new import pattern.The change from named import to namespace import aligns with the Zod v4 standardization effort across the codebase.
playgrounds/nest/src/contract/sse.ts (1)
2-2: LGTM: Import standardization is consistent.The namespace import change aligns with the codebase-wide standardization for Zod v4 support.
playgrounds/nest/src/reference/reference.service.ts (1)
2-2: Monitor experimental feature usage.The switch to
experimental_ZodToJsonSchemaConverterfrom@orpc/zod/zod4is appropriate for Zod v4 support, but note that experimental features may have stability considerations for production use.playgrounds/astro/src/schemas/auth.ts (2)
1-1: LGTM: Import standardization is consistent.The namespace import change aligns with the codebase-wide standardization effort.
4-4: Email validator syntax confirmed
z.email()is the correct, preferred way to define an email schema in Zod v4. The code inplaygrounds/astro/src/schemas/auth.tsis valid and no changes are needed.playgrounds/contract-first/src/schemas/auth.ts (1)
1-1: LGTM: Import standardization is consistent.The namespace import change aligns with the codebase-wide standardization effort.
playgrounds/electron/src/main/schemas/auth.ts (1)
1-1: LGTM: Import style updated for Zod v4 consistency.The namespace import aligns with the codebase-wide migration to Zod v4.
playgrounds/browser-extension/entrypoints/background/schemas/auth.ts (1)
1-1: LGTM: Consistent import style migration.The namespace import change aligns with the codebase-wide Zod v4 migration.
playgrounds/nest/src/schemas/auth.ts (1)
1-1: LGTM: Consistent migration pattern.Excellent consistency across all auth schema files in the migration to namespace imports.
apps/content/docs/server-action.md (1)
16-16: LGTM: Documentation updated for Zod v4 consistency.All code examples in the documentation have been properly updated to use namespace imports, ensuring they remain functional and consistent with the codebase migration.
Also applies to: 73-73, 140-140
apps/content/docs/client/server-side.md (1)
20-20: LGTM: Documentation examples updated consistently.All Zod import statements have been properly migrated to namespace imports, maintaining consistency with the Zod v4 migration across the codebase.
Also applies to: 37-37, 54-54, 73-73
playgrounds/astro/src/pages/api/[...rest].ts (1)
4-4: Consistent migration approach across playgrounds.The change maintains consistency with other playground files in the migration to the experimental ZodToJsonSchemaConverter. The aliasing approach ensures existing code continues to work.
packages/zod/README.md (1)
75-75: Good standardization of Zod import style.The change from named import to namespace import (
import * as z from 'zod') standardizes the import pattern across the codebase, improving consistency.README.md (2)
71-71: Excellent import standardization in main documentation.The change to namespace import style (
import * as z from 'zod') ensures consistency between the main README and the rest of the codebase documentation.
180-180: Consistent experimental converter usage in main docs.The migration to the experimental ZodToJsonSchemaConverter aligns with the broader Zod v4 migration effort and maintains consistency across all documentation.
apps/content/docs/openapi/getting-started.md (2)
51-51: Consistent Zod import pattern in user documentation.The namespace import style aligns with the standardized pattern across the codebase and provides a consistent example for users following the getting started guide.
174-176: Clear multi-line import format for experimental converter.The multi-line import format improves readability while maintaining consistency with the migration to the experimental ZodToJsonSchemaConverter from the zod4 subpath.
apps/content/docs/openapi/openapi-specification.md (2)
119-119: LGTM: Simplified email validation using Zod v4 API.The change from
z.string().email()toz.email()is a cleaner and more direct approach in Zod v4.
251-252: LGTM: Improved file validation with explicit MIME types.The migration from
oz.file().type(...)toz.file().mime([...])provides better type safety and explicit MIME type validation, which is more robust than wildcard patterns.apps/content/docs/file-upload-download.md (2)
20-20: LGTM: Consistent namespace import pattern.The change to namespace import (
import * as z from 'zod') is consistent with the v4 migration across the codebase.
23-23: LGTM: Proper Zod v4 file validation.Using
z.file()instead ofz.instanceof(File)is the correct approach for file validation in Zod v4, providing better integration with the schema system.playgrounds/browser-extension/entrypoints/background/schemas/planet.ts (3)
1-1: LGTM: Consistent namespace import.The namespace import pattern aligns with the Zod v4 migration strategy across the codebase.
11-11: LGTM: Comprehensive image MIME type validation.The explicit MIME type list
['image/png', 'image/jpeg', 'image/webp', 'image/svg+xml', 'image/gif']provides robust validation for common web image formats, which is more precise than the previous wildcard approach.Also applies to: 18-18
25-25: LGTM: Simplified URL validation.Using
z.url()instead ofz.string().url()is a cleaner API in Zod v4.playgrounds/electron/src/main/schemas/planet.ts (1)
1-1: LGTM: Consistent schema updates across playgrounds.The changes are identical to the browser extension playground, maintaining consistency in:
- Namespace import pattern
- Comprehensive image MIME type validation
- Simplified URL validation with
z.url()This consistency across playgrounds is excellent for maintainability.
Also applies to: 11-11, 18-18, 25-25
apps/content/docs/advanced/validation-errors.md (3)
19-19: LGTM: Consistent namespace import pattern.The namespace import changes are consistent with the Zod v4 migration across the documentation.
Also applies to: 58-58, 110-110
89-90: LGTM: Simplified UUID validation.Using
z.uuid()instead ofz.string().uuid()is a cleaner API in Zod v4.Also applies to: 123-123
34-35: No changes needed:z.prettifyError()andz.flattenError()are the correct Zod v4 APIs
Both methods are the recommended way to formatZodErrorinstances in Zod v4 (replacing the olderror.flatten()), so the existing snippets at lines 34–35 (and similarly at 71–72 and 139–140) are accurate.playgrounds/nest/src/schemas/user.ts (1)
1-37: Excellent migration to Zod v4 patterns!The changes successfully implement the v4 migration by:
- Standardizing to namespace imports (
import * as z from 'zod')- Using the experimental JSON schema registry from
@orpc/zod/zod4- Simplifying email validation to
z.email()- Separating schema definitions from example metadata
The implementation is clean and follows consistent patterns across the codebase.
playgrounds/browser-extension/entrypoints/background/schemas/user.ts (1)
1-37: Consistent migration pattern implemented correctly.This file follows the same v4 migration pattern as other playground files, maintaining consistency across the codebase. All changes align with the Zod v4 conventions.
playgrounds/astro/src/schemas/user.ts (1)
1-37: Migration implemented consistently.The Zod v4 migration is applied correctly with the same pattern as other playground files, ensuring consistency across the entire codebase.
playgrounds/contract-first/src/schemas/planet.ts (3)
1-1: Import standardization applied correctly.The namespace import for Zod aligns with the v4 migration pattern used throughout the codebase.
11-11: File validation migration implemented properly.The transition from
oz.file().type('image/*')toz.file().mime([...])with explicit MIME types is well-executed. The comprehensive list of image MIME types (image/png,image/jpeg,image/webp,image/svg+xml,image/gif) provides better type safety and clarity.Also applies to: 18-18
25-25: URL validation simplified correctly.The change from
z.string().url()toz.url()follows Zod v4 conventions and provides more direct validation.playgrounds/contract-first/src/schemas/user.ts (1)
1-37: Complete and consistent v4 migration.This file completes the migration pattern seen across all playground user schemas. The implementation maintains consistency and follows all Zod v4 conventions properly.
playgrounds/astro/src/schemas/planet.ts (3)
1-1: LGTM! Namespace import aligns with Zod v4 migration.The change from named import to namespace import (
import * as z from 'zod') is consistent with the broader migration pattern across the codebase.
11-11: Verify MIME type coverage for image validation.The explicit MIME type list is more secure than wildcards, but ensure all required image formats are covered. The current list includes PNG, JPEG, WebP, SVG, and GIF.
Consider if additional formats like AVIF or TIFF should be included based on your application requirements.
Also applies to: 18-18
25-25: LGTM! URL validation simplification is appropriate.The change from
z.string().url()toz.url()leverages Zod's direct URL validator, which is cleaner and more semantic.playgrounds/electron/tsconfig.json (1)
2-18: LGTM! TypeScript configuration consolidation looks well-structured.The configuration consolidation and explicit compiler options provide better control over the build process. The path mapping and module resolution settings are appropriate for an Electron application.
playgrounds/electron/src/main/schemas/user.ts (2)
9-9: LGTM! Email validation simplification is appropriate.The change from
z.string().email()toz.email()leverages Zod's direct email validator, which is more semantic and aligns with v4 patterns.Also applies to: 26-26
13-21: LGTM! Separation of examples from schema definitions improves modularity.The external registration of examples via the JSON schema registry provides better separation of concerns and makes schemas more focused on validation logic.
Also applies to: 29-37
playgrounds/nest/src/schemas/planet.ts (4)
1-1: LGTM! Consistent namespace import pattern.The namespace import aligns with the migration pattern used across other playground files.
11-11: LGTM! Consistent MIME type specification across playgrounds.The explicit MIME type list matches the pattern used in other playground files, maintaining consistency across the codebase.
Also applies to: 18-18
25-25: LGTM! URL validation simplification is consistent.The change to
z.url()matches the pattern used in other schema files.
15-15: No breaking change: schemas consistently use z.number()Searches across all service and client schema definitions did not find any use of
z.coerce.number(). EveryUpdatePlanetSchemaandPlanetSchemadefinesidasz.number().int().min(1)and all router, OpenAPI handlers, and client contracts expect numeric
idvalues. Removing coercion has no effect—no endpoints were accepting string-encoded numbers.packages/zod/src/converter.test.ts (1)
11-15: LGTM! Test structure simplification improves maintainability.Removing the
ignoreZodToJsonSchemaflag and external library comparison simplifies the test structure and focuses on testing the internal converter implementation.
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull Request Overview
This PR upgrades Zod from v3 to v4 across the entire codebase, adapting to the new API changes and schema methods.
Key Changes:
- Updated all Zod imports to use namespace imports (
import * as z from 'zod') - Migrated to Zod v4's native schema methods (e.g.,
z.email(),z.url(),z.file().mime([...])) - Replaced custom OpenAPI schema wrapper with external JSON schema registry approach
Reviewed Changes
Copilot reviewed 143 out of 144 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| All schema files (user.ts, planet.ts, auth.ts) | Updated to use native Zod v4 methods and namespace imports |
| All router/handler files | Updated imports to namespace style |
| All package.json files | Upgraded Zod dependency from ^3.25.76 to ^4.0.5 |
| packages/zod/src/* | Updated internal imports to use 'zod/v3' compatibility layer |
| Configuration files | Simplified TypeScript configurations and removed unused dependencies |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Summary by CodeRabbit
New Features
Refactor
z.string().email()toz.email(),z.string().uuid()toz.uuid(),z.string().url()toz.url()).z.file().mime([...]).Documentation
Chores