Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/react-router
SDK Version
10.44.0
Framework Version
React Router 7.13.0
Link to Sentry event
https://stagtech.sentry.io/issues/101940091/?project=4510804972798032&query=release%3A326b772c6b3e5039a956e96e67346ee387124681
Reproduction Example/SDK Setup
Minimal reproduction
npx create-react-router@latest sentry-repro --yes
cd sentry-repro
npm install @sentry/react-router @sentry/cli
vite.config.ts (per official docs):
import { reactRouter } from "@react-router/dev/vite";
import { sentryReactRouter, type SentryReactRouterBuildOptions } from "@sentry/react-router";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";
const sentryConfig: SentryReactRouterBuildOptions = {
org: "test-org",
project: "test-project",
authToken: process.env.SENTRY_AUTH_TOKEN,
};
export default defineConfig((config) => ({
build: { sourcemap: "hidden" },
plugins: [reactRouter(), sentryReactRouter(sentryConfig, config), tsconfigPaths()],
}));
react-router.config.ts:
import type { Config } from "@react-router/dev/config";
import { sentryOnBuildEnd } from "@sentry/react-router";
export default {
ssr: true,
buildEnd: async ({ viteConfig, reactRouterConfig, buildManifest }) => {
await sentryOnBuildEnd({ viteConfig, reactRouterConfig, buildManifest });
},
} satisfies Config;
Build and check:
SENTRY_AUTH_TOKEN=fake npx react-router build 2>&1 # errors on upload are expected (fake token)
grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' build/client/assets/entry.client-*.js | sort | uniq -c
Result: two different UUIDs in a single file — one from the Vite plugin's renderChunk, one from sentry-cli sourcemaps inject called by sentryOnBuildEnd.
Root cause
makeCustomSentryVitePlugins.js sets sourcemaps: { disable: 'disable-upload' }, which disables the upload but not debug ID injection. The Rollup plugin checks options.sourcemaps?.disable !== true, and 'disable-upload' !== true → injection still happens.
Then sentryOnBuildEnd calls sentry-cli sourcemaps inject which doesn't find a //# debugId= comment (because writeBundle was also skipped), so it injects a second snippet with a different UUID.
At runtime, the Vite plugin's snippet overwrites sentry-cli's in the _sentryDebugIds map. The SDK sends the Vite plugin's UUID, but the upload has sentry-cli's UUID → mismatch → js_no_source.
Suggested fix
Same approach as #15109 for Next.js. In makeCustomSentryVitePlugins.js:
sourcemaps: {
- disable: 'disable-upload',
+ disable: true,
...unstable_sentryVitePluginOptions?.sourcemaps,
},
Workaround
const sentryConfig: SentryReactRouterBuildOptions = {
// ...
unstable_sentryVitePluginOptions: {
sourcemaps: { disable: true },
},
};
Steps to Reproduce
- npx create-react-router@latest sentry-repro --yes
- Add sentryReactRouter + sentryOnBuildEnd per the official docs (see above)
- SENTRY_AUTH_TOKEN=fake npx react-router build
- grep -oE '[0-9a-f]{8}-...-[0-9a-f]{12}' build/client/assets/entry.client-*.js | sort | uniq -c
- Observe two different UUIDs in the same file
Expected Result
Each output file should contain exactly one debug ID, matching the uploaded source map artifact. Source maps should resolve correctly.
Actual Result
Two different UUIDs per file — one from the Vite plugin (renderChunk), one from sentry-cli (sentryOnBuildEnd). The SDK sends the wrong one, source maps never resolve.
Additional Context
This is the same bug as #15106, which was fixed for Next.js/webpack in #15109 by changing sourcemaps.disable from a workaround value to true. The React Router/Vite integration needs the same one-line fix in makeCustomSentryVitePlugins.js.
Priority
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/react-router
SDK Version
10.44.0
Framework Version
React Router 7.13.0
Link to Sentry event
https://stagtech.sentry.io/issues/101940091/?project=4510804972798032&query=release%3A326b772c6b3e5039a956e96e67346ee387124681
Reproduction Example/SDK Setup
Minimal reproduction
npx create-react-router@latest sentry-repro --yes cd sentry-repro npm install @sentry/react-router @sentry/clivite.config.ts (per official docs):
react-router.config.ts:
Build and check:
Result: two different UUIDs in a single file — one from the Vite plugin's
renderChunk, one fromsentry-cli sourcemaps injectcalled bysentryOnBuildEnd.Root cause
makeCustomSentryVitePlugins.jssetssourcemaps: { disable: 'disable-upload' }, which disables the upload but not debug ID injection. The Rollup plugin checksoptions.sourcemaps?.disable !== true, and'disable-upload' !== true→ injection still happens.Then
sentryOnBuildEndcallssentry-cli sourcemaps injectwhich doesn't find a//# debugId=comment (becausewriteBundlewas also skipped), so it injects a second snippet with a different UUID.At runtime, the Vite plugin's snippet overwrites sentry-cli's in the
_sentryDebugIdsmap. The SDK sends the Vite plugin's UUID, but the upload has sentry-cli's UUID → mismatch →js_no_source.Suggested fix
Same approach as #15109 for Next.js. In
makeCustomSentryVitePlugins.js:sourcemaps: { - disable: 'disable-upload', + disable: true, ...unstable_sentryVitePluginOptions?.sourcemaps, },Workaround
Steps to Reproduce
Expected Result
Each output file should contain exactly one debug ID, matching the uploaded source map artifact. Source maps should resolve correctly.
Actual Result
Two different UUIDs per file — one from the Vite plugin (renderChunk), one from sentry-cli (sentryOnBuildEnd). The SDK sends the wrong one, source maps never resolve.
Additional Context
This is the same bug as #15106, which was fixed for Next.js/webpack in #15109 by changing
sourcemaps.disablefrom a workaround value totrue. The React Router/Vite integration needs the same one-line fix inmakeCustomSentryVitePlugins.js.Priority
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it.