`wrangler types` emits `declare const Buffer: any` since v4.122.0, nullifying the `@types/node` Buffer interface

[JacktheRanger]

What versions & operating system are you using?

  System:
    OS: macOS 27.0
    CPU: (10) arm64 Apple M5
    Memory: 2.37 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 26.4.0 - /opt/homebrew/bin/node
    npm: 11.17.0 - /opt/homebrew/bin/npm
  npmPackages:
    wrangler: ^4.123.0 => 4.123.0

Also relevant (not covered by envinfo):

• typescript: 5.9.3
• @types/node: 22.20.1

Introduced in 4.122.0. Verified against 4.122.0 and 4.123.0 (both broken) and 4.121.0 (fine).

Please provide a link to a minimal reproduction

https://github.com/JacktheRanger/Wrangler-bug-reproduction

Describe the Bug

Summary

Since 4.122.0, wrangler types adds these two lines to the generated worker-configuration.d.ts:

declare const Buffer: any;
declare const process: any;

declare const Buffer: any collides with @types/node's var Buffer: BufferConstructor. The
resulting symbol conflict discards the members of the global interface Buffer from
@types/node, leaving only the Uint8Array shell it extends. skipLibCheck swallows the
duplicate-declaration error inside the .d.ts files, so nothing surfaces until a call site fails
with a confusing error far from the actual cause.

process is silently widened to any the same way. That one produces no error, it just removes
type checking from every process.* use in the project.

Steps to reproduce

1. wrangler.jsonc with "compatibility_date": "2026-08-04" (or later) and nodejs_compat
2. tsconfig.json with "types": ["./worker-configuration.d.ts", "node"]
3. Any Buffer.toString(encoding) call, e.g. pbkdf2Sync(...).toString('base64')
4. npx wrangler types && npx tsc --noEmit

Actual

src/index.ts(7,39): error TS2554: Expected 0 arguments, but got 1.

It is not just toString. Every Buffer-only member is gone, while members inherited from
Uint8Array still resolve — which is what pins the cause to the interface being nullified rather
than a single bad overload:

src/probe.ts(3,5): error TS2339: Property 'readUInt8' does not exist on type 'NonSharedBuffer'.
src/probe.ts(4,5): error TS2339: Property 'equals' does not exist on type 'NonSharedBuffer'.
src/probe.ts(5,5): error TS2339: Property 'toJSON' does not exist on type 'NonSharedBuffer'.

(buf.subarray(0, 4) on the same value type-checks fine.)

Expected

wrangler types should not emit declarations that override @types/node. Either omit
Buffer/process from the generated globals and let @types/node provide them, or declare them
with real types instead of any.

Worth noting the same release's changelog says wrangler types "no longer attributes its
@types/node suggestion to the nodejs_compat flag" — so Wrangler recommends installing
@types/node, and then emits a declaration that breaks it. Under nodejs_compat the Node typings
are the accurate ones for these globals, so any is strictly worse than deferring to them.

Note this only affects globals declared as const. The same batch emits
declare const global: ServiceWorkerGlobalScope (a concrete type, arguably better than
@types/node's typeof globalThis) and setImmediate/clearImmediate as function
declarations, which merge as overloads and cause no harm. Buffer and process are the only two
emitted as : any.

Regression range

wrangler	declare const X: any emitted	tsc --noEmit
4.121.0	none	clean
4.122.0	Buffer, process	TS2554
4.123.0	Buffer, process	TS2554

Likely from the 4.122.0 change that infers nodejs_compat from the compatibility date — our
compat date is exactly 2026-08-04, the day the flag became the default.

Workaround

Post-processing the generated file to strip top-level constants declared as any:

generated.replace(/^declare const [A-Za-z_$][A-Za-z0-9_$]*: any;\r?\n/gm, '')

In the generated output those are exactly Buffer and process; everything else declared at the
top level has a concrete type, so this leaves the rest of the runtime types untouched.

Please provide any relevant error logs

$ npx wrangler types
 ⛅️ wrangler 4.123.0
Generating project types...
Generating runtime types...
Runtime types generated.
✨ Types written to worker-configuration.d.ts

$ grep -n '^declare const [A-Za-z_$][A-Za-z0-9_$]*: any;$' worker-configuration.d.ts
440:declare const Buffer: any;
441:declare const process: any;

$ npx tsc --noEmit
src/index.ts(7,39): error TS2554: Expected 0 arguments, but got 1.

$ npx wrangler@4.121.0 types && npx tsc --noEmit
# (no any-typed globals emitted, tsc exits 0)

[workers-devprod]

• Reproduction: ✅ Successfully reproduced. wrangler 4.123.0 emits declare const Buffer: any and declare const process: any in worker-configuration.d.ts (4.121.0 does not). With node types installed this causes TS2554 and TS2339 errors as Buffer-only methods disappear from the type.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15215

Summary

Since wrangler 4.122.0, wrangler types emits declare const Buffer: any; and declare const process: any; into worker-configuration.d.ts, which collide with @types/node globals — silently discarding the real Buffer interface members and widening process to any.

Classification

• Type: Bug
• Component: packages/wrangler (wrangler types command)
• Severity: High
• Has Reproduction: Yes (with link)
• Quality: Complete

Findings

• Created: not confirmable (metadata truncated in context.json)
• Author: JacktheRanger (Jack)
• Version: wrangler 4.123.0; regression introduced in 4.122.0 (verified 4.121.0 is fine)
• Labels: not confirmable (metadata truncated in context.json)
• Comments: not confirmable (metadata truncated in context.json)

Note on data quality: context.json is a single-line file whose body field exceeds the tooling's 2000-character read limit. As a result, the trailing metadata (created date, labels, comment count, issue state) could not be extracted with the available read/grep tools. The classification below is based entirely on the fully-readable issue body, which is complete and self-contained.

Analysis

• Clear regression with a bisected version boundary. The reporter pins the break to 4.122.0 and confirms 4.121.0 works, which narrows the search to whatever changed in the wrangler types runtime-globals output between those releases.
• Well-diagnosed root cause. The report explains the mechanism precisely: declare const Buffer: any conflicts with @types/node's var Buffer: BufferConstructor, the symbol collision drops the global interface Buffer members (leaving only the Uint8Array shell), and skipLibCheck hides the duplicate-declaration error so the failure only surfaces at a distant call site (e.g. TS2554: Expected 0 arguments, but got 1 on .toString('base64')). process is silently widened to any, removing type-checking on all process.* usage.
• Reproduction provided and minimal. A dedicated repro repo is linked plus concise step-by-step instructions (nodejs_compat + compatibility_date: 2026-08-04, tsconfig types: ["./worker-configuration.d.ts", "node"], then wrangler types && tsc --noEmit).
• Broad user impact. Any project combining nodejs_compat with @types/node is affected, and the process: any widening silently degrades type safety project-wide without any error — a subtle correctness regression.
• Likely fix area: the type generation for injected runtime globals in the wrangler types code path. The emitted declare const Buffer/process: any should be omitted (or emitted conditionally / with a compatible type) when the user also pulls in @types/node, rather than shadowing the Node globals with any.

Recommendation

Status: KEEP OPEN

Reasoning: This is a high-quality, reproducible regression in wrangler types with a precise root-cause analysis and a clear version boundary (broke in 4.122.0). It affects a common configuration (nodejs_compat + @types/node) and silently weakens type safety, so it warrants a fix.

Action: Route to the Wrangler team owning the wrangler types command. Investigate the change between 4.121.0 and 4.122.0 that started emitting declare const Buffer: any / declare const process: any, and make the generated globals coexist with @types/node (omit or narrow these declarations when Node types are present). Confirm the applied labels/state directly on GitHub, since they could not be read from context.json.

Suggested Labels: none (label set could not be verified from the truncated context.json; confirm/apply appropriate package:wrangler and feature:types labels on GitHub if not already present)

Suggested Comment

Thanks for the detailed report and the minimal reproduction — the root-cause write-up is really helpful. This does look like a regression introduced in 4.122.0 where wrangler types began emitting declare const Buffer: any and declare const process: any, which shadow the @types/node globals and (via skipLibCheck) surface only as confusing downstream errors. We'll investigate the change in the wrangler types global generation so these declarations coexist with @types/node. We'll follow up here with progress.

Structured summary (JSON)

{
  "issueNumber": 15215,
  "title": "wrangler types emits `declare const Buffer: any` / `declare const process: any` that collide with @types/node",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15215",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "High-quality, reproducible regression in `wrangler types` (broke in 4.122.0) where injected `declare const Buffer/process: any` shadow @types/node globals, discarding Buffer members and widening process to any. Common config, silent type-safety loss.",
  "suggestedAction": "Route to the Wrangler team owning `wrangler types`; bisect the 4.121.0->4.122.0 change and make generated globals coexist with @types/node (omit/narrow when Node types are present).",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[JacktheRanger]

Follow-up with a narrower repro of the trigger condition. I originally guessed this came from the
4.122.0 "infer nodejs_compat from the compatibility date" change — that's now confirmed, but the
condition is narrower than I described, and it surfaces an inconsistency.

Tested on wrangler@4.123.0 with a minimal Worker (just wrangler.jsonc + src/index.ts),
counting ^declare const (Buffer|process): any;$ in the generated worker-configuration.d.ts:

compatibility_date	compatibility_flags	any globals emitted
2026-08-03	(none)	0
2026-08-04	(none)	2
2026-08-03	["nodejs_compat"]	0
2025-01-01	["nodejs_compat"]	0
2026-08-04	["nodejs_compat"]	2

Two things this pins down

1. The compatibility date is the only switch, to the day. 2026-08-03 emits nothing;
2026-08-04 emits both. Nothing else in the config matters.

2. An explicit nodejs_compat flag does not trigger it. This is the part that looks wrong
independently of the any typing: a Worker that explicitly opts into nodejs_compat on an older
compatibility date gets no Node globals in its generated types, while a Worker that gets Node
compat implicitly from the date gets them. Both have Node.js compatibility enabled at runtime, so
the two paths should agree — and today the explicit one is arguably the one that ought to be
emitting them.

So whatever the fix is for the : any typing, it may be worth aligning the two detection paths at
the same time.

Side effect worth noting for anyone else hitting this

Projects that already list nodejs_compat explicitly can drop their compatibility date to
2026-08-03 and the problem disappears with no loss of Node compatibility (the flag still provides
it). That's a real escape hatch, though the compatibility date gates more than just this flag, so
it shouldn't be taken as a general recommendation.