Why source maps matter in production?

Source maps are often thought of as a development-only tool — something your browser uses to show readable stack traces during local development. But they play a critical role in production too, and mishandling them is a real security risk.

What minification hides

When your app goes to production, the build process minifies your code — it strips whitespace, shortens variable names, and merges files into compact bundles. The result is fast to download but impossible for humans to read. If something crashes, the error points to line 1, column 48,293 of a single giant file. Not helpful.

How Sentry brings it back

A source map is a file that maps the minified code back to your original source. Upload your source maps to Sentry during the build, and every production error shows the exact file and line from your original code — as if minification never happened. That's the difference between "something broke somewhere" and "the crash is on line 42 of checkout.ts."

The security trap

Source maps contain your entire original source code — every file, every comment, every variable name. If you accidentally publish them alongside your production bundle, anyone can open browser dev tools and read your code as if it were open source.

This isn't hypothetical. In March 2026, Anthropic's Claude Code CLI shipped a source map file to the npm registry by mistake. Within hours, the entire 512,000-line TypeScript codebase was downloaded and mirrored across GitHub. The cause was simple: their bundler generates source maps by default, and nobody excluded the .map file from the published package.

What to do

Generate source maps, but keep them private:

• Upload to Sentry during your build so errors are readable
• Exclude from public bundles — your build config should skip .map files in production output, or your deploy pipeline should strip them before serving

The rule is straightforward: source maps are for your tools, not for your visitors.