Setup Browser SDK Sourcemaps

Set up Datadog sourcemap upload via the build plugin

Adds build-time sourcemap upload to a frontend project using the Datadog build plugin. Sourcemaps are uploaded as part of the build, so every deploy ships un-minified stack traces to RUM and Error Tracking. Git metadata is attached automatically, which links errors back to source files.

Follow steps 1-7 in order.

Before starting any work: Create exactly 7 todo items — one per step below. Do not begin implementation until all 7 todos are created. Do not compress or merge steps.

Never invent a value. Three fields (service, releaseVersion, minifiedPathPrefix) must match how the app is actually deployed. If you cannot read a value from the repo, stop and ask the user. Do not write a placeholder, a TODO, or a guessed hostname.

Scope

In scope: projects built by esbuild, Rollup, Rspack, Vite, or webpack — including meta-frameworks that expose one of these directly in their own config file (e.g. Remix/React Router v7+ framework mode, SvelteKit, Nuxt via vite.config.ts/nuxt.config.ts's vite: key). If Step 1's config-file search below finds a real bundler config, the meta-framework sitting on top of it does not change anything — wire the plugin into that config file exactly as normal.

Out of scope: Next.js and Turbopack specifically. Unlike the meta-frameworks above, Next.js does not expose a plain webpack/Turbopack config surface the plugin can hook into — it has no Next.js or Turbopack integration at all. For those, use the datadog-ci sourcemaps upload CLI in a postbuild script instead — do not attempt to thread the webpack plugin through next.config.js.

If a project uses some other meta-framework not listed here and Step 1 finds no plain bundler config file to edit, stop and ask rather than guessing whether it's supported.

Step 1: Detect the bundler

Search for a bundler config file:

find . -maxdepth 1 \( -name "vite.config.*" -o -name "rollup.config.*" -o -name "webpack.config.*" -o -name "rspack.config.*" -o -name "esbuild.config.*" \) 2>/dev/null
grep -l -E "\"(vite|rollup|webpack|@rspack/core|esbuild)\"" package.json

Use find, not ls with these glob patterns directly — in zsh, an ls invocation with multiple glob patterns aborts with no matches found the moment any one pattern fails to match, even with 2>/dev/null appended, because the failure happens during shell word-expansion before ls ever runs. find does its own pattern matching internally, so it works identically in bash and zsh and correctly returns nothing (not an error) when no bundler config exists.

Map the result:

Supported bundler versions:

Stop and ask the user if: no bundler config is found, more than one is found (monorepo — ask which app to instrument), Next.js or Turbopack is detected (out of scope, see above), or the bundler version is outside the supported range.

Step 2: Collect the three required values

The plugin will not build without these three. Read them from the repo; ask the user for anything you cannot read.

service — must equal the service passed to datadogRum.init(). Datadog matches uploaded sourcemaps to incoming errors on this value. A mismatch means the sourcemaps upload successfully and are never used.

grep -rn "datadogRum.init" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" -A 15

If the grep finds no datadogRum.init() call anywhere, stop: this skill only adds sourcemap upload to an existing RUM setup, it does not instrument RUM itself. Tell the user Browser RUM needs to be set up first, then re-run this skill.

If datadogRum.init() has no service, stop and tell the user: sourcemaps cannot be matched without it, and it must be added to the RUM init first.

releaseVersion — must equal the version passed to datadogRum.init(). Typically a git commit SHA, release tag, or CI build ID. Can be set here, or once at the top level as metadata.version. If both are set and differ, the build fails with sourcemaps.releaseVersion must match metadata.version when both are configured.

minifiedPathPrefix — the URL prefix the built JS is served from. Must be a full URL or start with /, otherwise the build fails with sourcemaps.minifiedPathPrefix must be a valid URL or start with '/'.

Worked example: if dist/main.js is served at https://example.com/static/main.js, then minifiedPathPrefix is https://example.com/static/ or /static/. If JS is served from the server root, / is valid.

This is the field most often wrong, and it cannot be derived from the bundler config alone. Before asking the user, check the repo for how it actually deploys:

1. Check the bundler's own base/publicPath/baseURL config first — if set, that already answers the question.
2. Otherwise check deploy/CI config for the actual deploy command and target directory: .github/workflows/*.yml, .gitlab-ci.yml, vercel.json, netlify.toml, wrangler.toml, Dockerfile. If the deploy step ships the bundler's output directory verbatim (e.g. pages deploy ./dist, netlify deploy --dir=build), the prefix is the bundler's default asset subdirectory relative to that root — Vite's default is /assets/, Create React App's is /static/js/, etc.
3. Check for path-rewrite config that could override the answer from step 2 above: Cloudflare _routes.json / _redirects, Netlify _redirects, Vercel rewrites in vercel.json. If any exist, re-derive the prefix from the rewrite rule instead of the raw build output path.
4. If none of the above resolves it — no committed deploy config, a custom domain/CDN configured only in a hosting dashboard — stop and ask the user. Give them a concrete way to check rather than just asking blind: open browser devtools on the live site, go to the Network tab, reload, and find the URL the main JS bundle actually loads from.

Do not write a placeholder, a TODO, or a guessed hostname even after checking all of the above.

Step 3: Install the plugin

npm install --save-dev @datadog/<bundler>-plugin

Use the project's package manager: yarn add -D, pnpm add -D, or bun add -d.

Step 4: Make the bundler emit sourcemaps

This is the most common silent failure. The plugin uploads whatever .map files the build produces. If the bundler is not configured to emit them it finds nothing, logs only a No sourcemaps to upload warning, and the build still succeeds. Nothing appears in Datadog and there is no error to explain why.

These are bundler-native settings, not plugin options. The Datadog build plugin does not set them and does not document them.

Add the setting if it is missing. If the project deliberately disables sourcemaps in production, stop and raise it with the user — hidden sourcemaps served publicly is a real concern, and the plugin uploads then deletes nothing, so the .map files still ship unless the deploy strips them.

Step 5: Wire the plugin into the config

Register the plugin first in the plugins array — the plugin's own README recommends this across all five bundlers for complete build reporting.

Do not put the API key in the config file. The plugin reads DATADOG_API_KEY (or DD_API_KEY) from the environment, and the environment takes precedence over the config value. Leaving it out keeps credentials out of version control.

Vite (vite.config.js):

import { defineConfig } from 'vite';
import { datadogVitePlugin } from '@datadog/vite-plugin';

export default defineConfig({
  build: { sourcemap: true },
  plugins: [
    datadogVitePlugin({
      errorTracking: {
        sourcemaps: {
          service: 'my-service',
          releaseVersion: process.env.GIT_COMMIT_SHA,
          minifiedPathPrefix: '/static/',
        },
      },
    }),
  ],
});

webpack (webpack.config.js):

const { datadogWebpackPlugin } = require('@datadog/webpack-plugin');

module.exports = {
  devtool: 'source-map',
  plugins: [
    datadogWebpackPlugin({
      errorTracking: {
        sourcemaps: {
          service: 'my-service',
          releaseVersion: process.env.GIT_COMMIT_SHA,
          minifiedPathPrefix: '/static/',
        },
      },
    }),
  ],
};

Rspack (rspack.config.js) — same as webpack, with datadogRspackPlugin from @datadog/rspack-plugin.

Rollup (rollup.config.js):

import { datadogRollupPlugin } from '@datadog/rollup-plugin';

export default {
  output: { sourcemap: true },
  plugins: [
    datadogRollupPlugin({
      errorTracking: {
        sourcemaps: {
          service: 'my-service',
          releaseVersion: process.env.GIT_COMMIT_SHA,
          minifiedPathPrefix: '/static/',
        },
      },
    }),
  ],
};

esbuild (build script):

const { datadogEsbuildPlugin } = require('@datadog/esbuild-plugin');

require('esbuild').build({
  sourcemap: true,
  plugins: [
    datadogEsbuildPlugin({
      errorTracking: {
        sourcemaps: {
          service: 'my-service',
          releaseVersion: process.env.GIT_COMMIT_SHA,
          minifiedPathPrefix: '/static/',
        },
      },
    }),
  ],
});

Replace every value with the ones collected in step 2. Do not leave 'my-service' or '/static/' in place.

Optional sub-options, only if the user asks: