Add the potential format parameter to the invalid type issue

[duncan3dc]

This is more of an issue than an actual fix, as I'm not familiar enough with the codebase to ensure this is valid, but I wanted to at least start with some code rather than just opening an issue.

I'm trying to declare an expected validation error, and typescript is saying it's invalid. Here's my expectation:

{
    code: "invalid_type",
    expected: "int",
    format: "safeint",
    message: "Invalid input: expected int, received number",
    path: ["sessions"],
}

And the typescript compiler is returning:
error TS2353: Object literal may only specify known properties, and 'format' does not exist in type '$ZodIssueInvalidType<unknown>'.

I tried to remove the format property from my expectation, but it is actually included in the zod response, so I'm presuming it's not correctly declared somewhere in this codebase...

[coderabbitai]

Walkthrough

The Zod error handling in the core module is getting an upgrade. A new import from the checks module brings in the $ZodNumberFormats type, and it's being added as an optional property to the $ZodIssueInvalidType interface. This lets the type errors now carry information about what number format was expected when validation fails. It's a targeted change to enrich the error details without breaking anything existing.

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "Add the potential format parameter to the invalid type issue" directly and accurately reflects the main change in the pull request. The title clearly communicates that a format parameter is being added to the $ZodIssueInvalidType interface, which matches what the raw summary shows. The title is concise, specific enough for someone reviewing history to understand the primary change, and avoids vague language.
Description Check	✅ Passed	The PR description is directly related to the changeset and provides meaningful context for why this change was needed. The author clearly explains the problem they encountered—a TypeScript error when declaring a validation error with a format property—and provides concrete examples of both the expected error object and the compiler error. The description demonstrates good reasoning about the issue and acknowledges uncertainty in a transparent way, which is helpful context for reviewers.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e6c0fd and 8d392ba.

📒 Files selected for processing (1)

• packages/zod/src/v4/core/errors.ts (2 hunks)

🧰 Additional context used

📓 Path-based instructions (9)

**/*.{js,jsx,ts,tsx,mjs,cjs,json}

📄 CodeRabbit inference engine (CLAUDE.md)

Enforce line width of 120 characters via Biome formatting

Files:

• packages/zod/src/v4/core/errors.ts

**/*.{js,jsx,ts,tsx,mjs,cjs}

📄 CodeRabbit inference engine (CLAUDE.md)

Use ES5-style trailing commas in JavaScript/TypeScript code

Files:

• packages/zod/src/v4/core/errors.ts

**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx}: Allow the any type in TypeScript (noExplicitAny off)
Allow non-null assertions in TypeScript (noNonNullAssertion off)
Write TypeScript to pass strict mode with exactOptionalPropertyTypes enabled
Use NodeNext module resolution semantics for imports in TypeScript
Target ES2020 language features in TypeScript source

Files:

• packages/zod/src/v4/core/errors.ts

**/*.{ts,tsx,js,jsx,mjs,cjs}

📄 CodeRabbit inference engine (CLAUDE.md)

Allow parameter reassignment for performance-sensitive code (noParameterAssign off)

Files:

• packages/zod/src/v4/core/errors.ts

**/*.{js,mjs,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/development-setup.mdc)

**/*.{js,mjs,ts,tsx}: Use .js extensions in import specifiers (e.g., import { z } from "./index.js")
Don’t use require(); use ESM import statements

Files:

• packages/zod/src/v4/core/errors.ts

**/*.{js,mjs,cjs,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/guidelines.mdc)

Do not leave log statements (e.g., console.log, debugger) in tests or production code

Files:

• packages/zod/src/v4/core/errors.ts

packages/zod/src/v4/core/errors.ts

📄 CodeRabbit inference engine (.cursor/rules/zod-internals.mdc)

Define and use canonical error types/codes as declared in errors.ts (e.g., invalid_type, TooBig/TooSmall, InvalidStringFormat, InvalidUnion, Custom)

Files:

• packages/zod/src/v4/core/errors.ts

packages/**/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/zod-project-guide.mdc)

Write source code in TypeScript (TypeScript-first codebase)

Files:

• packages/zod/src/v4/core/errors.ts

packages/zod/**

📄 CodeRabbit inference engine (.cursor/rules/zod-project-guide.mdc)

Make core Zod library changes in the main package at packages/zod/

Files:

• packages/zod/src/v4/core/errors.ts

🧠 Learnings (5)

📚 Learning: 2025-10-21T17:27:32.477Z

Learnt from: CR
PR: colinhacks/zod#0
File: .cursor/rules/zod-internals.mdc:0-0
Timestamp: 2025-10-21T17:27:32.477Z
Learning: Applies to packages/zod/src/v4/core/errors.ts : Define and use canonical error types/codes as declared in errors.ts (e.g., invalid_type, TooBig/TooSmall, InvalidStringFormat, InvalidUnion, Custom)

Applied to files:

• packages/zod/src/v4/core/errors.ts

📚 Learning: 2025-10-21T17:26:08.263Z

Learnt from: CR
PR: colinhacks/zod#0
File: .cursor/rules/testing-guidelines.mdc:0-0
Timestamp: 2025-10-21T17:26:08.263Z
Learning: Applies to packages/zod/src/{v4/classic/tests,v4/core/tests,v3/tests}/**/*.test.ts : Import Zod in tests as `import * as z from "zod/v4"`

Applied to files:

• packages/zod/src/v4/core/errors.ts

📚 Learning: 2025-10-21T17:26:08.263Z

Learnt from: CR
PR: colinhacks/zod#0
File: .cursor/rules/testing-guidelines.mdc:0-0
Timestamp: 2025-10-21T17:26:08.263Z
Learning: Applies to packages/zod/src/{v4/classic/tests,v4/core/tests,v3/tests}/**/*.test.ts : Use import type for type-only imports in tests (e.g., `import type { ... }`)

Applied to files:

• packages/zod/src/v4/core/errors.ts

📚 Learning: 2025-10-21T17:26:08.263Z

Learnt from: CR
PR: colinhacks/zod#0
File: .cursor/rules/testing-guidelines.mdc:0-0
Timestamp: 2025-10-21T17:26:08.263Z
Learning: Applies to packages/zod/src/{v4/classic/tests,v4/core/tests,v3/tests}/**/*.test.ts : Do not skip tests due to type issues; fix the types instead

Applied to files:

• packages/zod/src/v4/core/errors.ts

📚 Learning: 2025-10-21T17:27:32.477Z

Learnt from: CR
PR: colinhacks/zod#0
File: .cursor/rules/zod-internals.mdc:0-0
Timestamp: 2025-10-21T17:27:32.477Z
Learning: Applies to packages/zod/src/v4/core/{schemas.ts,core.ts} : Use the custom constructor system via core.$constructor() and initialize instances with $ZodType.init() when creating schemas

Applied to files:

• packages/zod/src/v4/core/errors.ts

🧬 Code graph analysis (1)

packages/zod/src/v4/core/errors.ts (1)

packages/zod/src/v4/core/checks.ts (1)

• $ZodNumberFormats (244-244)

🔇 Additional comments (2)

packages/zod/src/v4/core/errors.ts (2)

1-1: LGTM! Import looks good.

The addition of $ZodNumberFormats to the import is clean and follows the project's ESM conventions with the .js extension.

---

22-22: Looks good! The runtime behavior checks out.

I confirmed that invalid_type errors do include the format field at runtime. In packages/zod/src/v4/core/checks.ts, the error creation code already assigns format: def.format when pushing invalid_type issues. Your type definition change aligns perfectly with this existing behavior—making it optional in the interface since not all invalid_type errors will have a format value. Nice fix! ✨

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}