Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); chore(deps): update peerdependency zod to v4 by renovate[bot] · Pull Request #255 · nuxt-modules/robots · GitHub
Skip to content

chore(deps): update peerdependency zod to v4 - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x
Open

chore(deps): update peerdependency zod to v4#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/zod-4.x

Conversation

@renovate

@renovaterenovateBot commented Dec 15, 2025

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
zod (source)>=3>=4.5.4ageconfidence

Release Notes

colinhacks/zod (zod)

v4.5.4

Compare Source

Commits:

v4.5.3

Compare Source

v4.5.2

Compare Source

Commits:

  • a354314 fix(docs): keep blog posts out of the docs collection (#​6484)
  • d378c42 ci: drop canary publishing from the release workflow (#​6487)
  • 212b941 fix(v4): let a prototype method getter answer a bare call so vi.spyOn works (#​6488)
  • e7576f5 docs(blog): let the page show through the navbar in dark mode (#​6489)
  • fedb06f fix(docs): match the blog TOC hover bar to the 2px active indicator
  • 6c932fc chore: bump devcontainer image to Node 24 (#​6470)
  • 6635d9d docs(blog): soften the "method memoization" attribution
  • 019ae29 fix(docs): drop ISR on the docs route so the home page hydrates
  • 652bb43 chore(docs): drop the scroll log from the route-change scroller
  • 571c8e8 fix(docs): render blog tabs with the stock fumadocs tab card
  • 9a193aa 4.5.2

v4.5.1

Compare Source

Commits:

  • 2e862db ci: gate the GitHub release and JSR publish on the version being live on npm
  • 8e03380 4.5.1

v4.5.0

Compare Source

Zod 4.5 is now available.

npm install zod@latest

At a glance:

z.compile()

You can now pre-compile any Zod schema using z.compile(schema). This dramatically speeds up parsing performance.

import*aszfrom"zod";constPlayer=z.object({username: z.string(),bio: z.string(),xp: z.number()});constCompiledPlayer=z.compile(Player);

A compiled schema can be used exactly like an uncompiled one. There are no special rules around compiled schemas. They're just faster.

Player.parse({ ... });CompiledPlayer.parse({ ... });// ~2x faster

On objects, arrays, and unions, this speeds up parsing by a factor of ~3–7. More complex schemas stand to benefit more than simpler ones.

Time per parse on a shared nanosecond axis, standard parser as a gray bar with the compiled time as a blue bar inside it: an array of 10 objects 377 ns to 68 ns (5.5x), a 20-key object 301 ns to 38 ns (7.8x), an array of 10 strings 241 ns to 33 ns (7.3x), a union of 3 objects 190 ns to 36 ns (5.3x), a 3-element tuple 119 ns to 33 ns (3.6x), a 5-key strict object 117 ns to 32 ns (3.7x), a discriminated union 92 ns to 27 ns (3.4x), a 5-key object 76 ns to 28 ns (2.8x); up to 7.8x faster when compiled

Time per parse by schema type, standard parser vs compiled — lower is better (benchmark)

Below are the Moltar benchmark results comparing Zod (compiled and uncompiled) against the Moltar ParseSafe bench.

Bar chart of operations per second on the moltar benchmark fixture, parseSafe category: Zod 4 compiled 47.5M, typia 45.3M, Zod 4 11.6M, valibot 1.8M, effect 1.7M, Zod 3 1.2M, arktype 152k, yup 121k

Throughput on the moltar benchmark fixture (parseSafe: returns a new object with unknown keys stripped) — higher is better (benchmark)

And the equivalent results for the Moltar AssertLoose bench. Tested against the new z.validate(schema, input) function (detailed later in the post).

Bar chart of operations per second on the moltar benchmark fixture, assertLoose category: typia 74.9M, arktype 66.2M, Zod 4 compiled 60.6M, Zod 4 6.5M, valibot 1.9M, effect 1.7M, Zod 3 1.2M, yup 124k

Throughput on the moltar benchmark fixture (assertLoose: returns a boolean, unknown keys allowed) — higher is better (benchmark)

Zod's entire test suite runs twice—once normally and again with auto-compilation enabled globally—to ensure perfect fidelity.

How it works

Under the hood, z.compile() walks the entire schema once and produces a hyperoptimized snippet of flat, loop-free JavaScript that can validate inputs far faster than a standard runtime validator. This snippet can be executed via new Function() (effectively a more powerful eval) to serve as a fast-path validator. Schemas use this to "fast check" validity, falling back to the regular runtime logic on validation failure to provide granular error information.

Take this simple Point schema:

constPoint=z.object({x: z.number(),y: z.number()});

Here is the generated snippet for it:

constisPoint=newFunction("input",` if (typeof input !== "object" || input === null) return false; if (typeof input.x !== "number") return false; if (typeof input.y !== "number") return false; return true;`);isPoint({x: 1,y: 2});// trueisPoint({x: "1"});// false

For the large majority of inputs, the generated function validates the data with the fastest logic JavaScript can express: straight-line typeof checks and property reads, with no interpreter in between. When it can't handle an input, Zod falls back to the standard parser.

This is the function Zod generates for the Player schema above:

if(typeofinput!=="object"||input===null||Array.isArray(input))returnINVALID;constv0=input["username"];if(typeofv0!=="string")returnINVALID;constv1=input["bio"];if(typeofv1!=="string")returnINVALID;constv2=input["xp"];if(typeofv2!=="number"||!Number.isFinite(v2))returnINVALID;constv3={"username": v0,"bio": v1,"xp": v2};returnv3;

Armed with the power of new Function(), this happens in-process at runtime. There is no need to integrate with your build system.

The compiled schema is purely additive on top of the existing schema. It tacks on the pre-compiled fast path for checking valid inputs. When invalid data is detected, it returns the INVALID symbol to signal that parsing should fall back to the uncompiled parser. This structurally prevents subtle deviations in error reporting between compiled and uncompiled variants.

import "zod/compile"

To compile every schema in an application, import zod/compile once at the top of your entry point. Every schema constructed after that import is automatically compiled the first time it's used to parse data.

import"zod/compile";// must come before modules that define schemasimport*aszfrom"zod";constschema=z.object({name: z.string()});schema.parse({name: "ok"});// compiled on first parse

It also works as a Node.js CLI flag, which guarantees it runs before any module defines a schema:

node --import zod/compile app.js

Or set preload in bunfig.toml or nub.jsonc.

{
"preload": ["zod/compile"]
}

All schemas benefit to varying degrees, though complex object/tuple/array schemas benefit more than simple scalar validators.

Read the docs, or the full technical writeup: Introducing z.compile()

z.creditCard()

A new string format: 12–19 digits, optionally separated by single spaces or hyphens, with a valid Luhn checksum. (#​5931)

z.creditCard().parse("4111 1111 1111 1111");// ✅z.creditCard().parse("4111 1111 1111 1112");// ❌ bad checksum

z.properties()

The multi-property counterpart to z.property(). (#​5912)

consthttpsUrl=z.instanceof(URL).check(
...z.properties({protocol: z.literal("https:"asstring),hostname: z.string().regex(z.regexes.domain),}));httpsUrl.parse(newURL("https://example.com"));// ✅httpsUrl.parse(newURL("http://localhost"));// ❌ protocol

z.deepPartial()

Back in functional form after being removed as a method in Zod 4. (#​5928)

constPost=z.object({title: z.string(),author: z.object({name: z.string(),email: z.string()}),});constPartialPost=z.deepPartial(Post);typePartialPost=z.output<typeofPartialPost>;// => { title?: string; author?: { name?: string; email?: string }}PartialPost.parse({author: {}});// ✅

The result is still a ZodObject, so .shape and .extend() keep working.

.exactPartial()

Like .partial(), but wraps each field in z.exactOptional() instead of z.optional(): keys may be omitted, but an explicit undefined is rejected. This matches TypeScript's Partial<> under exactOptionalPropertyTypes. (#​6065)

constRecipe=z.object({title: z.string(),servings: z.number()});constPartialRecipe=Recipe.exactPartial();PartialRecipe.parse({});// ✅PartialRecipe.parse({title: undefined});// ❌

In Zod Mini it's a top-level function: z.exactPartial(Recipe).

z.validate()

Standalone boolean validation, in Zod, Zod Mini, and Zod Core. It answers "is this input valid?" without constructing a ZodError, which makes rejection cheap: on invalid input it is up to 16x faster than .safeParse().success. The return type is a guard on the schema's input type, and z.validateAsync() covers schemas with async refinements. (#​6471)

z.validate(z.string(),"hi");// truez.validate(z.string(),42);// false

z.input() / z.output()

Project a schema onto its input or output side. Useful for validating the two halves of a codec independently. (#​5928)

constisoDate=z.codec(z.iso.datetime(),z.date(),{decode: (s)=>newDate(s),encode: (d)=>d.toISOString(),});constEvent=z.object({name: z.string(),at: isoDate});z.input(Event).parse({name: "launch",at: "2024-01-01T00:00:00Z"});// ✅z.output(Event).parse({name: "launch",at: newDate()});// ✅

This is a no-op on schemas not containing codecs/pipes.

z.toZod<T>()

A utility to define a Zod schema that agrees exactly with a static type, often one that is handwritten or externally defined. (#​5913)

typePlayer={username: string;xp: number};constPlayer=z.toZod<Player>()(z.object({username: z.string(),xp: z.number(),}));Player.shape.username;// ZodString — the schema is returned unchanged

z.getDiscriminatedOption()

Extract a discriminated union member by discriminator value. (#​5947)

constFruit=z.object({type: z.literal("fruit"),seeds: z.boolean()});constVeg=z.object({type: z.literal("vegetable"),leafy: z.boolean()});constProduce=z.discriminatedUnion("type",[Fruit,Veg]);z.getDiscriminatedOption(Produce,"fruit");// typeof Fruitz.getDiscriminatedOption(Produce,"meat");// ❌ TypeScript error

Cyclical inputs

Zod recursive schemas now support cyclical data. For bundle size reasons, Zod Mini requires you to register a memoizer explicitly. (#​6387, #​6482)

Zod

constCategory=z.object({name: z.string(),getsubcategories(){returnz.array(Category);},});constinput: any={name: "root",subcategories: []};input.subcategories.push(input);constresult=Category.parse(input);result.subcategories[0]===result;// true

Zod Mini

// register a memoizer before defining any schemasz.config({memoizer: z.memoizer()});constresult=Category.parse(input);result.subcategories[0]===result;// true

9x reduction in schema memory footprint

In Zod 4.4 a bare z.string() retained 7.5kb of heap. In Zod 4.5 it retains 784 bytes.

Bar chart of heap retained by one schema instance, zod 4.4.3 versus 4.5: a 10-key object 82.0kb to 11.0kb, a union 17.5kb to 2.13kb, z.string().min(1) 16.7kb to 3.37kb, a record 16.4kb to 2.64kb, z.string().optional() 12.6kb to 1.50kb, an array of strings 11.2kb to 1.93kb, z.string() 7.53kb to 784b, z.number() 4.44kb to 706b. Up to 9.8x smaller than 4.4.3.

Retained heap per schema instance, Zod 4.4.3 vs 4.5 (benchmark)

In Zod 4.4 and earlier, all schema methods were automatically bound to the instance itself. This allowed users to pluck methods from schemas without causing issues due to this-binding.

const{ parse }=z.string();parse("some data");

A consequence of this is that each bound method allocates space on the heap; method implementations are not shared across all instances via prototype, as you'd expect. Zod 4.5 implements a method memoization pattern that avoids allocating bound methods until they are actually accessed.

Read the deep dive: Reducing Zod's memory footprint by an order of magnitude

Faster failures

Zod .parse()/.safeParse() instantiates a JavaScript Error, which captures a stack trace. In the case of validation failures, this is often much slower than the parsing logic itself. When using .safeParse(), Zod no longer captures this stack trace, speeding up failure-path parses by a factor of ~7.5x. (#​6316, #​6450)

constresult=Player.safeParse({username: 42,bio: "hello",xp: 12});result.success;// false — ~7.5x faster than Zod 4.4
Bar chart of time per failing safeParse: zod 4.4 at 6.3 microseconds, zod 4.5 at 840 nanoseconds — 7.6x faster

Player schema (benchmark)

Symbol keys in z.object()

A shape can now declare a symbol key. TypeScript tracks it: a const symbol infers as unique symbol, so z.infer makes the key required and checks its value type. Undeclared symbol keys are still ignored. (#​6448)

constTAG=Symbol("tag");constschema=z.object({name: z.string(),[TAG]: z.number()});schema.parse({name: "alice",[TAG]: 42});// ✅ { name: "alice", [TAG]: 42 }schema.safeParse({name: "alice"});// ❌ the symbol key is required

Bug fixes

All of these fix soundness issues, so a schema that relied on the old behavior may now reject input it used to accept.

⚠️z.iso.datetime() requires seconds

RFC 3339 mandates seconds. z.iso.datetime() and z.iso.datetime({ offset: true }) no longer accept minute-precision input like 2020-01-01T06:15Z. local: true still admits 2020-01-01T06:15, since an unqualified datetime is outside RFC 3339 either way. (#​6457)

z.iso.datetime().parse("2020-01-01T06:15:00Z");// ✅z.iso.datetime().parse("2020-01-01T06:15Z");// ❌ was accepted in 4.4

To accept both forms, union the two precisions:

z.union([z.iso.datetime(),z.iso.datetime({precision: -1})]);
⚠️ String length counts code points

.min(), .max(), and .length() counted UTF-16 code units, so z.string().max(5) rejected five emoji. They now count Unicode code points, which is what every non-JS consumer of a length bound does (Postgres, MySQL, Go, Python, and the maxLength that z.toJSONSchema() emits). .max() only loosens; .min() and .length() tighten for astral input. Graphemes are unchanged — a ZWJ sequence is still several code points. (#​6441)

z.string().max(5).parse("😀😀😀😀😀");// was too_big, now passesz.string().min(5).parse("😀😀😀");// was fine, now too_small

Closes #​3355.

⚠️ Record keys and intersections match TypeScript

A record's key schema now governs only the keys that match it, the way TypeScript treats an index signature. Intersecting an object with a pattern-keyed record no longer rejects the object's own keys. (#​6412)

z.object({name: z.string()}).and(z.record(z.string().regex(/^S_/),z.string())).parse({name: "a",S_a: "s"});// 4.4: throws invalid_key on "name"// 4.5: { name: "a", S_a: "s" }

Separately, an unrecognized_keys issue no longer aborts the schema it came from, so a strict object with an extra key and a bad value now reports both issues instead of just the first. Closes #​2200, #​2573, #​4017, #​5663.

⚠️__proto__ is always stripped

Object and record parsers now drop a __proto__ key whether it comes from the input, is declared by the schema, or is produced by a record key transform. A key that a record's key schema normalizes to __proto__ is dropped too. .strict() reports an own __proto__ input key as unrecognized_keys instead of silently swallowing it. Error formatters and both JSON Schema converters use own-property writes so a toString or constructor path segment can't walk onto Object.prototype (#​6213, #​6367, #​6346). (#​6386, #​6354, #​6355, #​6221)

⚠️ Stricter string formats
  • z.ipv6() validated by handing the string to new URL(), which let ::@1\ and ::1\n through. It now checks the address alphabet directly (#​6442).
  • z.ulid() restricts the first character to 07; anything higher overflows the 48-bit timestamp. A fixture that doesn't start with a real timestamp, such as one with a leading letter, is now rejected (#​6095).
  • z.httpUrl() enforces the RFC 1035 length limits on the host, matching z.hostname() (#​6035).
  • z.emoji() no longer backtracks exponentially on a failed match (#​6347).
  • z.string().includes(sub, { position: N }) emits a JSON Schema pattern that allows at least N leading characters, matching String.prototype.includes (#​6024).

Commits

Zod 4.5 rolls up 155 commits. Thanks to everyone who contributed: @​dokson, @​deepshekhardas, @​zirkelc, @​francisjohnjohnston-web, @​MerlijnW70, @​codinsonn, @​oimo23, @​JSap0914, @​zelinewang, @​abhishek-chaudhary2003, @​spokodev, @​Mohammad-Faiz-Cloud-Engineer, @​hamed-bavar, @​MGPOCKY, @​ChiChuRita, @​dinwwwh, @​thristhart, @​tsmartin9, @​vedanshshetti, @​belicam, @​frastefanini, @​andersk, @​musaddiq-rafi, @​tachmyratsaparmyradov, @​arvindfroi, @​KUMachine, @​spidersouris, @​catdalfonso, @​mneetika, @​gwagjiug, @​MahinAnowar, @​MaksZhukov, @​emmayusufu, @​agcty, @​devareddy05, @​Vish05, @​yamcodes, @​mattiasahlsen, @​samchungy, @​ozzyfromspace, @​udohjeremiah, @​patrickwehbe, @​gajus, @​Harm-Nullix, @​thwbh, @​IdanGonen, @​irfanfandi, @​JuerGenie, @​marcalexiei, @​itsahmedbilal, @​DucMinhNe, @​meliharik.

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from c40eb90 to 0bb473fCompareDecember 16, 2025 04:31
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 3 times, most recently from 27ff1f3 to e608e78CompareJanuary 4, 2026 10:40
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from d67d4ca to e685dcaCompareJanuary 22, 2026 22:13
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from be00fe8 to 9597fabCompareFebruary 17, 2026 18:02
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from f6a1915 to 982689eCompareMarch 5, 2026 16:51
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 982689e to 391f8d2CompareApril 1, 2026 22:02
@pkg-pr-new

pkg-pr-newBot commented Apr 1, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nuxtjs/robots@255

commit: 3659cba

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 4 times, most recently from aadf846 to 7cd182cCompareMay 4, 2026 12:04
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 7cd182c to 0889bd3CompareMay 12, 2026 14:18
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 63a0c74 to 55ceff2CompareMay 27, 2026 04:37
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 55ceff2 to 3dc88fbCompareJuly 18, 2026 23:35
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch from 3dc88fb to cba8378CompareAugust 8, 2026 19:02
@github-actions

github-actionsBot commented Aug 8, 2026

Copy link
Copy Markdown

📦 Package Size

No notable size changes

All tracked output (10)
Package outputGzippedRaw
@nuxtjs/robots · dependency @fingerprintjs/botd13 kB55 kB
@nuxtjs/robots · dependency h334 kB146 kB
@nuxtjs/robots · dependency nuxt-site-config10 kB25 kB
@nuxtjs/robots · dependency nuxtseo-shared23 kB76 kB
@nuxtjs/robots · export .5.3 kB20 kB
@nuxtjs/robots · export ./content292 B503 B
@nuxtjs/robots · export ./util6.6 kB25 kB
@nuxtjs/robots · published payload36 kB121 kB
@nuxtjs/robots · app runtime2.5 kB6.2 kB
@nuxtjs/robots · server runtime8.6 kB22 kB
Runtime dependencies (10)
PackageDependencyRequestedResolvedCost
@nuxtjs/robots@fingerprintjs/botd^2.0.02.0.0📦 13 kB gzip
@nuxtjs/robots@nuxt/kit^4.5.24.5.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsconsola^3.4.23.4.2♻️ free via Nuxt 4.5.2
@nuxtjs/robotsdefu^6.1.76.1.7♻️ free via Nuxt 4.5.2
@nuxtjs/robotsh3^1.15.111.15.11📦 34 kB gzip
@nuxtjs/robotsnuxt-site-config^4.2.34.2.3📦 10 kB gzip
@nuxtjs/robotsnuxtseo-shared^5.3.145.3.14📦 23 kB gzip
@nuxtjs/robotspathe^2.0.32.0.3♻️ free via Nuxt 4.5.2
@nuxtjs/robotspkg-types^2.3.12.3.1♻️ free via Nuxt 4.5.2
@nuxtjs/robotsufo^1.6.41.6.4♻️ free via Nuxt 4.5.2

Baseline: main_@_4697167___2026-08-21 · gzip is the comparison metric · changes below 16 B gzip are ignored

@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from e36728d to 67c55feCompareAugust 11, 2026 17:33
@renovate
renovateBotforce-pushed the renovate/zod-4.x branch 2 times, most recently from 2912756 to 34fe523CompareAugust 26, 2026 10:40
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants