Summary
A production stack trace stops being a dead end.
The frames come back as real files and lines with the surrounding code attached, and the trace can be handed over as a raw crash payload from Sentry, Bugsnag or Datadog rather than copied out by hand first.
What it is
A source-map reader for production errors. Give it a stack trace full of hashed bundle names and column offsets, and it returns the original files, lines and columns — plus the code around them. The running server answers with seven tools.
What you get
- A minified stack trace decoded into original TypeScript locations, with the frames it could not map counted rather than dropped
- The source lines surrounding a mapped location, with a pointer at the column
- A check that the .map files in a dist directory line up with the compiled .js files they claim to describe
- Verification that a production bundle matches its source map, using the Debug IDs embedded in both
- Bundler-specific paths — webpack://, ng://, Vite's /@fs/ — resolved to real files on disk
- Crash payloads from Sentry, Bugsnag or Datadog ingested directly and returned as retraced frames
- Async boundaries followed, so a frame that surfaced inside a microtask can be traced back to what scheduled it
Requirements
Node, through the published npm package, and the .map files for the build that produced the trace — the retrace is only as good as the maps you point it at.
Setup effort
One command — npx -y sourcemap-retrace-mcp