gotchajavascriptModerate

Source maps for Sentry: resolving minified stack traces to original source

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

@sentry/webpack-plugin ^2.x

source mapsSentry releasesentry-webpack-pluginminified stack traceurl-prefixupload sourcemapsAPP_VERSION

Problem

Sentry shows stack traces pointing to minified production bundles: at a.b (main.abc123.js:1:45823). These are useless for debugging. The original file names, line numbers, and variable names are lost.

Solution

Upload source maps to Sentry at deploy time so stack traces are resolved server-side to original source.

Option 1: Sentry webpack plugin (recommended):

// webpack.config.js
const { sentryWebpackPlugin } = require('@sentry/webpack-plugin');

module.exports = {
  devtool: 'source-map',
  plugins: [
    sentryWebpackPlugin({
      org: 'my-org',
      project: 'my-project',
      authToken: process.env.SENTRY_AUTH_TOKEN,
      release: { name: process.env.APP_VERSION },
    }),
  ],
};

Option 2: Sentry CLI in CI:

npx @sentry/cli releases files $VERSION upload-sourcemaps ./dist \
  --url-prefix '~/static/js' --rewrite

Critical: Set the release in Sentry.init() to the same value used when uploading source maps.

Why

Source maps contain the mapping from minified bundle positions back to original source positions. Sentry uses them server-side so you never expose source maps publicly in your web server.

Gotchas

The release string in Sentry.init() and in the source map upload MUST match exactly — even a trailing slash difference breaks resolution
Never serve source maps publicly — they expose your entire source code; upload to Sentry only
url-prefix must match the URL path where the bundle is served, e.g., ~/static/js not ~/
esbuild source maps omit some metadata that Sentry needs — use the Sentry esbuild plugin, not just --sourcemap

Context

Getting readable stack traces in Sentry for a production JavaScript application

Revisions (0)

No revisions yet.