Support true VS Code “launch” debugging for Workers with reliable breakpoints

[mannok]

Cloudflare Workers would benefit from first-class VS Code launch-mode debugging, where developers can press F5 and have the full debug session start automatically: local Worker runtime, debugger attachment, source-map resolution, breakpoint binding, and process cleanup.

Today, the documented workflow is primarily an attach experience: start wrangler dev separately, then attach VS Code to the inspector. While attach debugging is useful, many developers expect the standard VS Code launch experience provided by modern frameworks and runtimes.

Desired Experience

1. Open a Worker project in VS Code.
2. Set a breakpoint in src/index.ts.
3. Select a Worker debug configuration.
4. Press F5.
5. Wrangler starts the local Worker runtime.
6. VS Code attaches to the correct Worker inspector target automatically.
7. TypeScript breakpoints bind reliably.
8. Stopping the debugger stops the local Worker dev process.

In other words, developers should not need to manually run wrangler dev first. The debug configuration should behave like a normal launch target, even if Wrangler internally starts workerd and VS Code attaches to an inspector.

Why This Matters

Worker debugging currently involves several moving pieces:

• wrangler dev starts the local runtime.
• workerd exposes the inspector.
• VS Code must attach to the correct target.
• Generated files and sourcemaps must map back to original TypeScript files.
• The dev server and debugger lifecycle need to stay coordinated.

If any part of this chain is misaligned, developers can run into hollow/unbound breakpoints, attachment to the wrong inspector target, or lingering dev processes after debugging stops.

Requested Outcome

• An official VS Code launch-style configuration for Workers.
• One-F5 debugging without manually starting wrangler dev.
• Reliable TypeScript breakpoint binding.
• Correct inspector target selection.
• Clean lifecycle behavior: debug start starts the Worker, debug stop stops it.
• Support for common Worker features such as Durable Objects, .dev.vars, compatibility flags, and local mode.
• Clear documentation for both simple and advanced Worker projects.

Possible Implementation Paths

• Add a Wrangler command to generate VS Code launch config.
• Document an official compound launch.json that behaves like launch debugging while handling internal attach details.
• Provide a stable inspector target or WebSocket endpoint suitable for VS Code.
• Improve sourcemap handling for generated .wrangler/tmp files.
• Include VS Code launch debugging setup in Cloudflare project templates.

This would make Workers debugging feel much closer to the experience developers get from modern Node, frontend, and full-stack frameworks, where pressing F5 starts the app and breakpoints work by default.