-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Standardize the Zod usage #2968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
💡 Enable Vercel Agent with $100 free credit for automated AI reviews |
WalkthroughReplaces local internal imports of zod from Changes
Sequence Diagram(s)(No sequence diagram — changes are import-only and do not alter application control flow.) Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Bulk, consistent import changes across many files with minimal heterogeneity; verify imports, a couple formatting tweaks, and the single removed console.log. Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (2)📓 Common learnings📚 Learning: 2025-10-17T08:18:19.258ZApplied to files:
⏰ 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). (1)
🔇 Additional comments (1)
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/web/scripts/tinybird/update-sale-event.ts (1)
59-81: SQL injection vulnerability in delete condition.The
delete_conditionon line 78 is constructed using unescaped string interpolation ofeventIdandoldValue. Malicious input could manipulate the query logic and cause unintended deletions.Consider parameterizing or properly escaping these values. If Tinybird's API supports parameterized queries, use that approach. Otherwise, validate and escape special characters (especially single quotes) before interpolation:
- body: `delete_condition=event_id='${eventId}' and ${columnName}='${oldValue}'`, + body: `delete_condition=event_id='${eventId.replace(/'/g, "''")}' and ${columnName}='${oldValue.replace(/'/g, "''")}'`,Better yet, implement proper input validation to ensure
eventIdandoldValueconform to expected formats before using them in queries.apps/web/scripts/tinybird/update-lead-event.ts (1)
64-74: Critical: SQL injection vulnerability in delete condition.The
delete_conditionparameter is constructed using unescaped string interpolation. While the current script uses hardcoded values, thedeleteDatafunction signature accepts parameters that are directly interpolated into the query string. If this function is ever reused with user-controlled input or ifoldValuefrom Tinybird contains malicious content, it could lead to injection attacks.Consider using proper parameterization or escaping. If Tinybird's API supports parameterized queries, use that. Otherwise, implement strict validation and escaping:
return fetch( `https://api.us-east.tinybird.co/v0/datasources/${dataSource}/delete`, { method: "POST", headers: { Authorization: `Bearer ${process.env.TINYBIRD_API_KEY}`, "Content-Type": "application/x-www-form-urlencoded", }, - body: `delete_condition=event_id='${eventId}' and ${columnName}='${oldValue}'`, + body: `delete_condition=event_id='${escapeSQL(eventId)}' and ${escapeSQL(columnName)}='${escapeSQL(oldValue)}'`, }, ).then((res) => res.json());You'll need to implement
escapeSQLto properly escape single quotes and other special characters, or check if Tinybird provides a safer API for deletions.
🧹 Nitpick comments (2)
apps/web/scripts/tinybird/update-lead-event.ts (1)
11-11: Consider replacingz.any()with a proper schema.Using
z.any()bypasses Zod's type safety and runtime validation. If the structure of the lead event data is known, consider defining a proper schema to catch errors early and provide better TypeScript inference.For example:
- data: z.any(), + data: z.object({ + event_id: z.string(), + event_name: z.string(), + // add other known fields + }).array(),If the structure truly varies, you could use
z.unknown()with downstream validation instead ofz.any().apps/web/app/app.dub.co/(dashboard)/account/settings/security/update-password.tsx (1)
11-17: Consider adding client-side validation for better UX.The form could integrate the imported
updatePasswordSchemawith react-hook-form's resolver (e.g., using@hookform/resolvers/zod) to provide immediate validation feedback before submission, improving the user experience.Example integration:
import { zodResolver } from "@hookform/resolvers/zod"; const { register, handleSubmit, setError, formState: { isSubmitting, isDirty, errors }, reset, } = useForm<z.infer<typeof updatePasswordSchema>>({ resolver: zodResolver(updatePasswordSchema), });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (59)
apps/web/app/(ee)/api/admin/revenue/get-top-programs-by-sales.ts(1 hunks)apps/web/app/(ee)/api/cron/domains/transfer/route.ts(1 hunks)apps/web/app/(ee)/api/cron/framer/backfill-leads-batch/route.ts(1 hunks)apps/web/app/(ee)/api/customers/route.ts(1 hunks)apps/web/app/(ee)/api/embed/referrals/earnings/route.ts(1 hunks)apps/web/app/(ee)/api/groups/[groupIdOrSlug]/partners/route.ts(1 hunks)apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts(1 hunks)apps/web/app/(ee)/api/stripe/integration/callback/route.ts(1 hunks)apps/web/app/(ee)/api/stripe/integration/route.ts(1 hunks)apps/web/app/(ee)/app.dub.co/embed/referrals/leaderboard.tsx(1 hunks)apps/web/app/api/ai/completion/route.ts(1 hunks)apps/web/app/api/domains/client/register/route.ts(1 hunks)apps/web/app/api/domains/client/saved/route.ts(1 hunks)apps/web/app/api/domains/default/route.ts(1 hunks)apps/web/app/api/domains/search-availability/route.ts(1 hunks)apps/web/app/api/links/[linkId]/transfer/route.ts(1 hunks)apps/web/app/api/oauth/apps/route.ts(1 hunks)apps/web/app/api/oauth/token/exchange-code-for-token.ts(1 hunks)apps/web/app/api/oauth/token/refresh-access-token.ts(1 hunks)apps/web/app/api/support/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/billing/usage/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/invites/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/saml/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/scim/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/upload-url/route.ts(1 hunks)apps/web/app/api/workspaces/[idOrSlug]/users/route.ts(1 hunks)apps/web/app/app.dub.co/(auth)/oauth/authorize/authorize-form.tsx(1 hunks)apps/web/app/app.dub.co/(auth)/oauth/authorize/page.tsx(2 hunks)apps/web/app/app.dub.co/(dashboard)/account/settings/security/update-password.tsx(1 hunks)apps/web/lib/api/domains/transform-domain.ts(1 hunks)apps/web/lib/api/links/bulk-update-links.ts(1 hunks)apps/web/lib/api/links/get-links-count.ts(1 hunks)apps/web/lib/api/links/get-links-for-workspace.ts(1 hunks)apps/web/lib/dynadot/register-domain.ts(1 hunks)apps/web/lib/dynadot/search-domains.ts(1 hunks)apps/web/lib/dynadot/set-renew-option.ts(1 hunks)apps/web/lib/integrations/hubspot/schema.ts(1 hunks)apps/web/lib/integrations/slack/commands.ts(1 hunks)apps/web/lib/integrations/slack/schema.ts(1 hunks)apps/web/lib/tinybird/record-link.ts(1 hunks)apps/web/lib/types.ts(1 hunks)apps/web/scripts/tinybird/update-lead-event.ts(1 hunks)apps/web/scripts/tinybird/update-sale-event.ts(1 hunks)apps/web/tests/analytics/index.test.ts(1 hunks)apps/web/tests/folders/index.test.ts(1 hunks)apps/web/tests/links/bulk-create-link.test.ts(1 hunks)apps/web/tests/links/create-link.test.ts(1 hunks)apps/web/tests/partners/analytics.test.ts(1 hunks)apps/web/tests/partners/resource.ts(1 hunks)apps/web/tests/utils/schema.ts(1 hunks)apps/web/tests/webhooks/index.test.ts(1 hunks)apps/web/tests/workspaces/retrieve-workspace.test.ts(1 hunks)apps/web/ui/auth/register/signup-email.tsx(1 hunks)apps/web/ui/auth/reset-password-form.tsx(1 hunks)apps/web/ui/modals/share-dashboard-modal.tsx(1 hunks)apps/web/ui/partners/groups/design/application-form/fields/index.tsx(2 hunks)apps/web/ui/partners/groups/design/application-form/program-application-form.tsx(1 hunks)apps/web/ui/partners/lander/blocks/index.tsx(1 hunks)
⏰ 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). (1)
- GitHub Check: build
🔇 Additional comments (56)
apps/web/lib/dynadot/set-renew-option.ts (1)
2-2: LGTM! Import correctly standardized.The change from the internal alias to the external
zodpackage using the standard named import is correct and aligns with the PR objective.apps/web/scripts/tinybird/update-sale-event.ts (1)
2-2: LGTM! Import standardization is correct.The change from the internal alias to the external
zodpackage using the standard named import pattern is appropriate and maintains identical functionality.apps/web/ui/partners/lander/blocks/index.tsx (1)
6-6: LGTM! Correct standardization of Zod import.The change from a default import to the standard named import
{ z }from the external "zod" package is correct. The usage ofz.inferremains functionally identical, and the approach of importing schemas from internal paths (line 1) while importing the core Zod library directly from the package is appropriate and consistent with the PR objectives.apps/web/lib/dynadot/search-domains.ts (1)
1-1: LGTM! Import standardization aligns with Zod's official API.The change from an internal default import to the named import
{ z }from thezodpackage is correct and follows Zod's standard usage pattern. This standardization improves consistency across the codebase.apps/web/ui/auth/reset-password-form.tsx (1)
8-8: LGTM! Clean standardization to external Zod import.The change correctly imports
zfrom the externalzodpackage using named import syntax. This aligns with the PR objective to standardize Zod usage across the codebase while keeping schema definitions organized in the internal library (@/lib/zod/schemas/auth).apps/web/scripts/tinybird/update-lead-event.ts (1)
2-2: LGTM! Import standardization is correct.The change from the internal alias to the external
zodpackage using the standard named import syntax is correct and aligns with the PR objective.apps/web/ui/auth/register/signup-email.tsx (1)
11-11: Import change is compatible with project's Zod version.The web package uses Zod ^3.22.4, which fully supports the named import syntax
import { z } from "zod". The standardization change is correct and safe to merge.apps/web/lib/integrations/slack/commands.ts (1)
7-7: Import change to external zod package verified and approved.The
zodpackage is properly declared inapps/web/package.json(version^3.22.4), making the import change from the internal alias to{ z }from "zod" correct and safe. The type-only usage ofz.inferon line 174 ensures no runtime behavior changes. No further action required.apps/web/app/(ee)/app.dub.co/embed/referrals/leaderboard.tsx (1)
15-15: No issues found. Migration is safe and maintains functionality.The internal
@/lib/zodwrapper re-exports the official zod package without custom configuration or extensions. The z.infer<> utility extracts types from schemas identically regardless of import source—it's a compile-time operation that doesn't depend on howzis imported. The change fromimport z from "@/lib/zod"toimport { z } from "zod"at line 15 is correct and safe.apps/web/app/app.dub.co/(dashboard)/account/settings/security/update-password.tsx (1)
7-7: Named import syntax is correct and fully compatible.The change to
import { z } from "zod"is appropriate. The project uses Zod ^3.22.4 in apps/web, which fully supports named exports. The import change maintains identical functionality and follows modern Zod conventions.apps/web/lib/dynadot/register-domain.ts (1)
1-1: Verification complete—change is correct and properly configured.The import change to
import { z } from "zod"is correct and verified:
- zod "^3.22.4" is available in apps/web/package.json
- No remaining
@/lib/zodimports in the codebase- The pattern aligns with existing files in the same directory
apps/web/tests/webhooks/index.test.ts (1)
17-17: LGTM! Zod standardization is complete and verified across the codebase.The import change from the internal
@/lib/zodalias to the standardzodnamed import is correct. Verification confirms:
- The old
@/lib/zodmodule has been removed entirely- Zero remaining imports from the old module across the codebase
- All files use the standard
import { z } from "zod";pattern- Project-specific schemas at
@/lib/zod/schemas/*remain properly in placeapps/web/lib/tinybird/record-link.ts (1)
2-2: Import change is correct; migration nearly complete (88% done).The
@/lib/zodfile is a simple re-export wrapper that applies the zod-openapi extension, so replacing it with a direct import from thezodpackage is safe and appropriate. The file uses the correct named import syntax{ z }which matches zod's export pattern.The systematic migration is nearly complete: 344 files have already switched to
import { z } from "zod", with 46 files still using the old alias. This change is one of the final updates.apps/web/tests/partners/resource.ts (1)
3-3: No issues; import change is safe for this test file.The change from
@/lib/zodto direct{ z } from "zod"is appropriate here. While@/lib/zoddoes extend Zod with OpenAPI support, this test file uses only standard Zod methods (z.object(),z.string(),.nullish()) and doesn't call any OpenAPI-specific methods. This aligns with the consistent pattern across all test files in the codebase, which use direct Zod imports. The lib schema files that require OpenAPI support continue to use@/lib/zod.apps/web/app/api/oauth/apps/route.ts (1)
12-12: LGTM - Clean refactor to external zod import.The change correctly separates the core zod library import from custom schema imports (
@/lib/zod/schemas/oauth), maintaining all existing functionality.apps/web/app/(ee)/api/groups/[groupIdOrSlug]/partners/route.ts (1)
12-12: LGTM - Consistent with standardization effort.apps/web/app/api/links/[linkId]/transfer/route.ts (1)
12-12: LGTM.apps/web/lib/api/domains/transform-domain.ts (1)
6-6: LGTM - Maintains type inference correctly.apps/web/app/(ee)/api/cron/framer/backfill-leads-batch/route.ts (1)
19-19: LGTM.apps/web/app/api/workspaces/[idOrSlug]/saml/route.ts (1)
8-8: LGTM.apps/web/app/api/oauth/token/exchange-code-for-token.ts (1)
12-12: LGTM.apps/web/app/api/domains/client/saved/route.ts (1)
4-4: The suggestion to remove @/lib/zod re-export is incorrect.The
@/lib/zodmodule is not a redundant alias. It exportszwithextendZodWithOpenApi(z)applied and is actively used in ~530 locations throughout the codebase (schema files, OpenAPI handlers, webhooks, and API error handlers). Removing it would break the zod-openapi integration that the entire system depends on. This PR's change to direct imports in a single route file does not affect this central abstraction.Likely an incorrect or invalid review comment.
apps/web/app/(ee)/api/admin/revenue/get-top-programs-by-sales.ts (1)
4-4: LGTM! Import standardization applied correctly.The change from the internal alias to the external zod package with a named import is correct and maintains full compatibility with the existing usage.
apps/web/lib/api/links/get-links-count.ts (1)
4-4: LGTM! Import standardization applied correctly.The switch to the external zod package with named import is correct and preserves existing type inference behavior.
apps/web/app/api/workspaces/[idOrSlug]/invites/route.ts (1)
13-13: LGTM! Import standardization applied correctly.The change to the external zod package maintains full compatibility with all schema definitions and validation logic in this route.
apps/web/app/api/workspaces/[idOrSlug]/upload-url/route.ts (1)
5-5: LGTM! Import standardization applied correctly.The import change maintains full compatibility with the schema definition for upload URLs.
apps/web/app/api/support/route.ts (1)
4-4: LGTM! Import standardization applied correctly.The switch to the external zod package preserves the support request validation schema behavior.
apps/web/app/api/domains/client/register/route.ts (1)
4-4: LGTM! Import standardization applied correctly.The import change maintains compatibility with the domain registration schema validation.
apps/web/app/api/workspaces/[idOrSlug]/users/route.ts (1)
12-12: LGTM! Import standardization applied correctly.The change to the external zod package maintains compatibility with all schema definitions for user role updates and removal.
apps/web/app/api/workspaces/[idOrSlug]/scim/route.ts (1)
5-5: LGTM! Import standardization applied correctly.The import change preserves all SCIM directory schema validation logic.
apps/web/app/(ee)/api/cron/domains/transfer/route.ts (1)
9-9: LGTM! Import standardization is correct.The switch from the internal zod wrapper to the external package maintains all functionality. The named import syntax
import { z } from "zod"is the standard approach.apps/web/lib/api/links/get-links-for-workspace.ts (1)
3-3: LGTM! Import standardization is correct.The change correctly switches to the external zod package while maintaining the schema import from
@/lib/zod/schemas/links(which is expected for application-specific schemas).apps/web/app/api/oauth/token/refresh-access-token.ts (1)
10-10: LGTM! Import standardization is correct.The migration to the external zod package is properly implemented with no impact on runtime behavior or type safety.
apps/web/app/api/ai/completion/route.ts (1)
9-9: LGTM! Import standardization is correct.The external zod import works seamlessly with the schema definition and parsing logic in this file.
apps/web/tests/workspaces/retrieve-workspace.test.ts (1)
4-4: LGTM! Test import standardization is correct.The external zod import maintains full compatibility with the test's schema extension and validation logic.
apps/web/lib/api/links/bulk-update-links.ts (1)
7-7: LGTM! Import standardization is correct.The switch to the external zod package maintains type inference and validation functionality without any issues.
apps/web/app/(ee)/api/partner-profile/programs/[programId]/earnings/route.ts (1)
11-11: LGTM! Import standardization is correct.The external zod import integrates properly with the schema validation and array parsing in this endpoint.
apps/web/app/api/domains/search-availability/route.ts (1)
6-6: Rewrite review comment to reflect verification findings.The review comment's verification request is based on incorrect assumptions. The
@/lib/zodwrapper file still exists atapps/web/lib/zod/index.tsand is actively used by approximately 46 files across the codebase. The wrapper exports a zod instance extended with OpenAPI support viazod-openapi. No migration of existing imports has occurred, and the old wrapper cannot be removed without breaking those dependencies.This single-file change to use a direct
zodimport is locally scoped and doesn't impact the rest of the codebase—the wrapper remains functional for other files. However, this introduces inconsistency: the reviewed file now imports directly from"zod"while the majority of the codebase continues to use the standardized wrapper.Likely an incorrect or invalid review comment.
apps/web/app/api/workspaces/[idOrSlug]/billing/usage/route.ts (1)
6-6: LGTM! Import change is correct.The migration from the internal alias to the external
zodpackage with a named import is correct and maintains identical functionality.apps/web/ui/modals/share-dashboard-modal.tsx (1)
27-27: LGTM! Import standardization applied correctly.The change to named import from the external
zodpackage is correct and preserves all type inference functionality.apps/web/app/(ee)/api/stripe/integration/callback/route.ts (1)
8-8: LGTM! Clean import migration.The standardization to the external
zodpackage is correct and maintains schema validation behavior.apps/web/app/api/workspaces/[idOrSlug]/route.ts (1)
20-20: LGTM! Import change preserves all schema functionality.The migration correctly maintains all advanced Zod features including schema extension, regex validation, and type unions.
apps/web/app/(ee)/api/embed/referrals/earnings/route.ts (1)
6-6: LGTM! Import standardization is correct.The change to the external
zodpackage maintains all coercion and array parsing functionality.apps/web/app/(ee)/api/customers/route.ts (1)
27-27: LGTM! Import migration preserves schema operations.The standardization correctly maintains all schema merging and parsing operations.
apps/web/lib/integrations/slack/schema.ts (1)
1-1: LGTM! Schema definitions remain fully compatible.The import change maintains all exported schema functionality including transformations and enums.
apps/web/app/api/domains/default/route.ts (1)
7-7: LGTM! Clean import standardization.The switch from the internal zod alias to the external package is correct, and all usages remain consistent.
apps/web/app/app.dub.co/(auth)/oauth/authorize/authorize-form.tsx (1)
11-11: LGTM!Import change aligns with the PR's standardization goal. Type inference usage remains correct.
apps/web/app/app.dub.co/(auth)/oauth/authorize/page.tsx (2)
11-11: LGTM!Import standardization is correct.
21-23: LGTM! Cleaner formatting.Function signature consolidation improves readability without changing behavior.
apps/web/tests/links/bulk-create-link.test.ts (1)
4-4: LGTM!Import standardization is consistent with the broader PR changes.
apps/web/tests/folders/index.test.ts (1)
4-4: LGTM!Import change is correct and maintains existing type inference patterns.
apps/web/tests/partners/analytics.test.ts (1)
3-3: LGTM!Import standardization is correct.
apps/web/ui/partners/groups/design/application-form/program-application-form.tsx (1)
29-29: LGTM!Import standardization is correct. All type inference patterns throughout the file remain consistent.
apps/web/tests/links/create-link.test.ts (1)
6-6: LGTM!Import change is correct and consistent with the PR's standardization goal.
apps/web/ui/partners/groups/design/application-form/fields/index.tsx (1)
2-2: LGTM! Zod import correctly standardized.The change from importing zod via the local alias to a direct import from the
zodpackage correctly implements the PR objective. The named import syntax is standard and the functionality remains unchanged.apps/web/tests/analytics/index.test.ts (1)
4-4: Import change looks correct.The migration from the internal
@/lib/zodalias to the externalzodpackage with named import syntax is appropriate and aligns with standard zod usage patterns.Verify that
@/lib/zodwas a simple re-export and didn't provide custom validation, configuration, or test utilities:
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1931 @devkiran, thank you for clarifying! I can see that This PR correctly standardizes the usage by moving to the standard ✏️ Learnings added
|
Summary by CodeRabbit
Chores
Bug Fixes