PR drafted with AI assistance.

Summary

Promotes globalConfig to a globalThis singleton, mirroring the dual-package fix already applied to globalRegistry in #5452. After this change, globalThis.__zod_globalConfig is the single source of truth for customError / localeError / jitless regardless of how Zod was loaded (CJS, ESM, multiple bundles in a monorepo).

// packages/zod/src/v4/core/core.ts
(globalThis as GlobalThisWithConfig).__zod_globalConfig ??= {};
export const globalConfig: $ZodConfig = (globalThis as GlobalThisWithConfig).__zod_globalConfig!;

Why

Today globalConfig is a fresh module-scope object on every load of Zod. In any project where some packages resolve zod as ESM and others as CJS — or where multiple bundles each carry their own copy — a single z.config({ jitless: true }) only mutates one of them.

#5789 is exactly this footgun in production:

After some more investigation I discovered that my monorepo was using zod in a few different places. Some still used CJS and some used ESM. This caused two instances of zod to be loaded in and so the initial config call was only being applied to one of the instances. I fixed this by calling z.config twice, once in the index of the main application to configure the ESM instances and once in one of the CJS package index files to configure the CJS instance.

globalRegistry already solved the same dual-package hazard in #5452. There's no good reason for globalConfig to behave differently — and it's surprising that it does, since they live in the same core/ directory.

Interaction with #5864 (allowsEval honours jitless)

Combined with #5864, this gives strict-CSP users a clean pre-import opt-out without any new API surface:

<script>globalThis.__zod_globalConfig = { jitless: true };</script>
<script type="module" src="app.js"></script>

That's strictly more general than the bespoke window.ZOD_NO_EVAL flag proposed in #5862 — it works in Node/workers/edge/browser, it covers every config field (not just eval), and it falls out of an existing pattern instead of introducing a new one. Closing #5862 in favor of this.

Compatibility

• No default-behaviour change. ??= preserves any pre-populated object on globalThis, and Object.assign(globalConfig, …) keeps mutating the same identity that z.config() and external pre-set scripts both observe. z.config() returns the same object identity for a given realm.
• Symmetric with the registry pattern. No versioned key (__zod_globalConfig, not __zod_globalConfig_v4), so cross-major loads share state. That's the same trade-off Fix dual package hazard for globalRegistry #5452 already accepted; if it's wrong for config it's also wrong for the registry. Easy to revisit if it bites someone.
• No public API change.

Refs #5789, #5862, #5452, #5864, #4461, #5414.

Test plan

• pnpm vitest run packages/zod/src/v4/classic/tests/global-config.test.ts — 3 new tests pass:
  • globalConfig is referentially equal to globalThis.__zod_globalConfig
  • z.config(...) writes are observed via globalThis.__zod_globalConfig
  • Pre-set globalThis.__zod_globalConfig is preserved on import
• pnpm vitest run — full suite, 3703/3703 pass (pre-push hook)
• pnpm lint — clean
• Existing jitless-allows-eval.test.ts (fix(core): honour jitless config in allowsEval probe #5864) still passes — confirms the globalConfig.jitless short-circuit still works through the new globalThis-backed object