workerd error: source map points to wrong file in local stack trace

TL;DR

The source map wrangler dev serves is stale or was generated for a different bundle than the one running. Do a clean rebuild (delete the previous build output), restart wrangler dev, and reproduce the error. If the trace still points at the wrong file, check that only one bundler pass is emitting source maps and that no transform (minify, transpile plugin) is rewriting files after the map was made.

workerd error: source map points to wrong file in local stack trace

1. Stop wrangler dev and remove any previous build artifacts:

rm -rf dist .wrangler

Expected: the directories are gone. Stale artifacts in .wrangler are the most common source of a wrong map.

1. Restart wrangler dev and reproduce the error immediately, without editing code in between:

wrangler dev

Expected: a fresh bundle and fresh source map are generated together.

1. Read the new stack trace and check whether the file names now match reality.

Expected: frames point at your actual source files and line numbers line up with the code. If they do, the old map was simply stale.

1. If it is still wrong, disable minification for the local build. Check wrangler.toml and any build config for minify settings, and run dev unminified.

Expected: unminified builds map 1:1 to source. Minifiers rewrite identifiers and line structure after the map is emitted, which skews every frame.

1. If a custom build step (esbuild plugin, vite, a second bundler) runs before wrangler, make sure only one step emits the final source map that workerd consumes. Two chained maps collapse incorrectly when the intermediate files are not preserved.

Expected: with a single map-emitting pass, frames resolve to the right files.

Use this when

• Local stack traces name files you did not write or lines that do not exist.
• The trace was correct yesterday and broke after a bundler or wrangler upgrade.
• Two files with similar names exist and the trace consistently picks the wrong one.

Not for this skill when

• The trace is correct but the error itself is mysterious. That is a runtime bug, not a mapping bug.
• Production (deployed) stack traces are wrong but local ones are fine. Check the deploy pipeline's map handling instead.
• No stack trace appears at all. That is a logging/exception-swallowing issue.

Variant phrasings

• wrangler dev stack trace wrong file
• workerd sourcemap incorrect line numbers
• cloudflare workers local dev stack trace misleading
• source maps broken after minify workers

Why it happens

workerd maps runtime errors back to source using the source map attached to the uploaded bundle. In local dev, wrangler rebuilds the bundle on each save, but the map workerd holds can lag the bundle (a rebuild raced the error, or an old artifact was reused). Minifiers and chained transpilers compound it: each transform shifts code, and if the final map does not account for every shift, every frame lands in the wrong file or line. The runtime trusts the map completely, so a bad map produces confidently wrong traces.

Edge cases

• TypeScript path aliases and monorepo symlinks can confuse the map's file paths. If traces point at ../../packages/... variants of your files, check tsconfig paths and how the bundler resolves them.
• Errors thrown during module evaluation (top-level code) sometimes map to the entry chunk rather than the real module. Reproduce inside a request handler to get accurate frames.
• wrangler dev --remote uses the deployed bundle's map, which may be older than your local code. Compare against a fresh deploy if remote traces look stale.
• Some editors open the mapped path instead of the real file; verify the file on disk before concluding the trace is wrong.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-1qqjiwgCPNygFE2Bx_YQ