Issue Review: cloudflare/workers-sdk#10020

Summary

wrangler types generates ambient namespace declarations for Cloudflare.Env that collide when multiple workers with different environments are type-checked together.

Findings

• Created: 2025-07-18
• Updated: 2025-11-14
• Version: wrangler 4.24.4 → 4.61.0
• Component: wrangler types
• Labels: bug
• Comments: 4

Key Evidence

• User has two workers with service bindings between them (organization → item)
• Each worker has its own Env interface (OrganizationEnv, ItemEnv)
• Generated worker-configuration.d.ts uses declare namespace Cloudflare { interface Env {...} }
• Ambient namespaces are global - one definition shadows the other
• Both OrganizationEnv and ItemEnv end up extending the wrong Cloudflare.Env
• Reporter provided working fix: avoid extending Cloudflare.Env, inline the fields directly
• Workarounds documented: manual edit of generated file, type assertion with cloudflare:workers env

Recommendation

Status: KEEP OPEN

Reasoning: Valid bug affecting multi-worker monorepos with service bindings. The use of ambient/global types causes namespace collisions. Multiple users have confirmed the issue and workarounds. The fix is conceptually straightforward: don't use ambient namespaces or make them unique per worker.

Action: Change wrangler types to generate unique namespace names per worker, or inline the interface fields directly instead of using extends Cloudflare.Env.

Suggested Comment

This is a known limitation of the current type generation approach. For users hitting this, there are workarounds:

1. Use @tv42's kludge function to post-process the generated types
2. Type-cast env from cloudflare:workers manually

A proper fix would change how wrangler types generates the Env interface to avoid global namespace collisions.