Skip to content

chore: update all non-major dependencies - #145

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/all-non-major-dependencies
Open

chore: update all non-major dependencies#145
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/all-non-major-dependencies

Conversation

@renovate

@renovate renovate Bot commented Jul 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@commitlint/cli (source) 21.2.1 → 21.2.2 age confidence
@commitlint/config-conventional (source) 21.2.0 → 21.2.2 age confidence
@tsconfig/node24 (source) 24.0.4 → 24.0.5 age confidence
@vercel/ncc 0.44.1 → 0.45.0 age confidence
lefthook 2.1.10 → 2.1.12 age confidence
oxfmt (source) 0.59.0 → 0.65.0 age confidence
oxlint (source) 1.74.0 → 1.80.0 age confidence
semantic-release 25.0.8 → 25.0.9 age confidence
tsx (source) 4.23.1 → 4.23.12 age confidence
vite (source) 8.1.5 → 8.2.2 age confidence
vitest (source) 4.1.10 → 4.1.11 age confidence
zod (source) 4.4.3 → 4.5.4 age confidence

Release Notes

conventional-changelog/commitlint (@​commitlint/cli)

v21.2.2

Compare Source

Note: Version bump only for package @​commitlint/cli

conventional-changelog/commitlint (@​commitlint/config-conventional)

v21.2.2

Compare Source

Note: Version bump only for package @​commitlint/config-conventional

tsconfig/bases (@​tsconfig/node24)

v24.0.5

Compare Source

vercel/ncc (@​vercel/ncc)

v0.45.0

Compare Source

Features
evilmartians/lefthook (lefthook)

v2.1.12

Compare Source

oxc-project/oxc (oxfmt)

v0.65.0

Compare Source

v0.64.0

Compare Source

🚀 Features
📚 Documentation

v0.63.0

Compare Source

v0.62.0

Compare Source

🐛 Bug Fixes

v0.61.0

Compare Source

v0.60.0

Compare Source

oxc-project/oxc (oxlint)

v1.80.0

Compare Source

v1.79.0

Compare Source

💥 BREAKING CHANGES
  • 8c4552d linter: [BREAKING] Split react/react-compiler into per-category rules (#​25500) (Boshen)
🐛 Bug Fixes
  • 228e8e0 linter: Resolve inactive React compiler rules (#​25830) (Boshen)
  • aa49d86 linter: Allow spread rule options in config types (#​25675) (ch3rry)
  • 36f8451 linter/eslint/no-eval: Align indirect default with ESLint (#​25656) (camc314)
  • beb724d linter/eslint/no-unused-vars: Report bare underscore parameters (#​25663) (camc314)
  • 4004c10 linter/eslint/no-irregular-whitespace: Check comments by default (#​25660) (camc314)
  • 285820e linter/no-large-snapshots: Precompile and document allowed snapshot matchers (#​25611) (Mikhail Baev)
  • 4df5835 linter: Allow capitalized built-in calls (#​25516) (Boshen)

v1.78.0

Compare Source

🚀 Features
  • ccb8fe8 linter/jsdoc: Implement no-blank-blocks rule (#​25207) (Mikhail Baev)
  • d4a897c linter/eslint: Implement one-var rule (#​24470) (Cole Ellison)
  • 5ab9340 linter/jsx-a11y/anchor-has-content: Add options to match eslint (#​24571) (Cole Ellison)
🐛 Bug Fixes
  • 9573937 linter/typescript: Validate ban-ts-comment description_format (#​25320) (Mikhail Baev)

v1.77.0

Compare Source

🐛 Bug Fixes
  • 5c0fa61 linter/eslint/no-warning-comments: Unify config structs and remove manual options docs (#​25151) (Mikhail Baev)
📚 Documentation
  • 9dc7756 linter/typescript/no-unnecessary-condition: Clarify options (#​25110) (camc314)

v1.76.0

Compare Source

🚀 Features
  • 8d31dfa linter: Verify eslint/no-restricted-globals config schema (#​24598) (vigneshwar)
  • 7069621 linter: Verify jest/vitest prefer-lowercase-title config schema (#​24724) (Bartok)
  • 016cf2a linter/oxc: Add bad-match-all-arg rule (#​24900) (camc314)
  • cdc941e linter/n: Implement exports-style rule (#​24087) (Mikhail Baev)
  • 1ad6f6c linter/eslint: Implement id-denylist rule (#​24632) (Mikhail Baev)
📚 Documentation

v1.75.0

Compare Source

🚀 Features
  • dd18383 linter/node: Implement no-top-level-await rule (#​24634) (Connor Shea)
  • 16a65f2 linter/react: Implement function-component-definition rule (#​24471) (Cole Ellison)
  • 7f1f585 linter: Reuse jest/padding-around-test-blocks for vitest/padding-around-test-blocks (#​24519) (Mikhail Baev)
  • 99978a8 linter/import/consistent-type-specifier-style: Support prefer-top-level-if-only-type-imports option (#​24502) (camc314)
🐛 Bug Fixes
  • 8694167 linter/eslint/prefer-destructuring: Handle typed declarations (#​24616) (camc314)
semantic-release/semantic-release (semantic-release)

v25.0.9

Compare Source

Bug Fixes
  • do not expose the authenticated repository URL in EGITNOPERMISSION errors (#​4283) (8d905a5)
privatenumber/tsx (tsx)

v4.23.12

Compare Source

Bug Fixes

This release is also available on:

v4.23.11

Compare Source

v4.23.10

Compare Source

Bug Fixes

This release is also available on:

v4.23.9

Compare Source

Bug Fixes
  • map Node test locations (2f55884)
  • support data URLs in tsImport (b94f46f)

This release is also available on:

v4.23.8

Compare Source

Bug Fixes
  • preserve package subpath resolution (be1315e)
  • preserve typeless ESM dependency exports (70dfc5e)

This release is also available on:

v4.23.7

Compare Source

Bug Fixes
  • prevent tsImport cache collisions (4e5a138)

This release is also available on:

v4.23.6

Compare Source

v4.23.5

Compare Source

v4.23.4

Compare Source

Bug Fixes
  • cli: allow async process.once() signal handlers to finish (#​827) (2afc7bb)

This release is also available on:

v4.23.3

Compare Source

Bug Fixes

This release is also available on:

v4.23.2

Compare Source

vitejs/vite (vite)

v8.2.2

Compare Source

Features
Bug Fixes
Documentation
Miscellaneous Chores
Code Refactoring
Tests
Build System
  • use JSON import attributes instead of readFIleSync in rolldown configs (#​23251) (d615bcd)

v8.2.1

Compare Source

Bug Fixes
Performance Improvements
Documentation
Miscellaneous Chores
Code Refactoring
Tests

v8.2.0

Compare Source

Features
Bug Fixes
  • bundledDev: print build errors to the terminal when an HMR update fails (#​23024) (41c4658)
  • deps: update all non-major dependencies (#​23069) (4c07b74)
  • hmr: preserve environment snapshot during server restart (#​22992) (b1186c3)
  • importAnalysis: interop imports injected into optimized dep files by plugins (#​23029) (8c2a87d)
  • module-runner: keep stack trace interception working when Object.prototype is frozen (#​23073) (599c5b0)
  • server: strip base in indexHtml module graph lookup (#​22932) (fa005d1)
  • support resolving top-level input option with plugins (#​23101) (41df81a)
Documentation
Tests
vitest-dev/vitest (vitest)

v4.1.11

Compare Source

   🐞 Bug Fixes
    View changes on GitHub
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 * as z from "zod";

const Player = z.object({
  username: z.string(),
  bio: z.string(),
  xp: z.number()
});

const CompiledPlayer = 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:

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

Here is the generated snippet for it:

const isPoint = new Function("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 }); // true
isPoint({ 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 (typeof input !== "object" || input === null || Array.isArray(input)) return INVALID;
const v0 = input["username"];
if (typeof v0 !== "string") return INVALID;
const v1 = input["bio"];
if (typeof v1 !== "string") return INVALID;
const v2 = input["xp"];
if (typeof v2 !== "number" || !Number.isFinite(v2)) return INVALID;
const v3 = { "username": v0, "bio": v1, "xp": v2 };
return v3;

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 schemas
import * as z from "zod";

const schema = 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)

const httpsUrl = z.instanceof(URL).check(
  ...z.properties({
    protocol: z.literal("https:" as string),
    hostname: z.string().regex(z.regexes.domain),
  })
);

httpsUrl.parse(new URL("https://example.com")); // ✅
httpsUrl.parse(new URL("http://localhost")); // ❌ protocol

z.deepPartial()

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

const Post = z.object({
  title: z.string(),
  author: z.object({ name: z.string(), email: z.string() }),
});

const PartialPost = z.deepPartial(Post);
type PartialPost = z.output<typeof PartialPost>;
// => { 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)

const Recipe = z.object({ title: z.string(), servings: z.number() });

const PartialRecipe = 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"); // true
z.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)

const isoDate = z.codec(z.iso.datetime(), z.date(), {
  decode: (s) => new Date(s),
  encode: (d) => d.toISOString(),
});

const Event = 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: new Date() });            // ✅

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)

type Player = { username: string; xp: number };

const Player = 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)

const Fruit = z.object({ type: z.literal("fruit"), seeds: z.boolean() });
const Veg = z.object({ type: z.literal("vegetable"), leafy: z.boolean() });
const Produce = z.discriminatedUnion("type", [Fruit, Veg]);

z.getDiscriminatedOption(Produce, "fruit"); // typeof Fruit
z.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

const Category = z.object({
  name: z.string(),
  get subcategories() {
    return z.array(Category);
  },
});

const input: any = { name: "root", subcategories: [] };
input.subcategories.push(input);

const result = Category.parse(input);
result.subcategories[0] === result; // true

Zod Mini

// register a memoizer before defining any schemas
z.config({ memoizer: z.memoizer() });

const result = 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)

const result = 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)

const TAG = Symbol("tag");
const schema = 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. (

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

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

@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 6 times, most recently from 0995fc1 to 8acea56 Compare August 10, 2026 14:46
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 9 times, most recently from 870346d to 638dac2 Compare August 17, 2026 12:08
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 5 times, most recently from 8afebf0 to 21de284 Compare August 26, 2026 15:54
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 3 times, most recently from 7f04ec4 to 5293a05 Compare September 3, 2026 00:56
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 3 times, most recently from 40bf44d to 8f04270 Compare September 5, 2026 04:45
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch from 8f04270 to 39995ed Compare September 5, 2026 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

A-dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants