@sentry/nextjs v11: tracing modules bundle even with tracesSampleRate: 0 — the default-integration import graph is static

[goranpopo]

Environment

@sentry/nextjs 11.0.0, Next 16.3.6 + Turbopack production build, tracesSampleRate: 0, explicit integrations: [rewriteFramesIntegration, thirdPartyErrorFilterIntegration].

What are you trying to achieve?

An error-only client SDK: performance tracing is off (tracesSampleRate: 0, no browserTracingIntegration registered), so the tracing machinery should not reach the bundle.

What happens instead?

The tracing stack still bundles. Measured from Turbopack's build analysis of a 47-route app, all present in every route's client chunks:

• browserTracingIntegration.js (@sentry/browser)
• tracing/sentrySpan.js, tracing/trace.js, tracing/idleSpan.js, spanUtils.js (@sentry/core)
• browser-utils/spans.js, request.js, fetch.js, appRouterRoutingInstrumentation.js (@sentry/nextjs)

Together ~30-40 kB gz per route. The modules arrive through the default-integration set that init wires statically, so passing an explicit integrations list does not remove them from the import graph — the filter runs after the imports.

Suggestion

When tracesSampleRate: 0 (and no tracesSampler), build the default integration list without the tracing family — statically, not at runtime — the same way the SDK already treats disabled features elsewhere. For an error-only app that is the single largest remaining dependency after react-dom.

[linear-code]

JS-3831

[andreiborza]

Hi @goranpopo, thanks for writing in.

A tracesSampleRate: 0 does not control what the bundler includes. There's a build time flag __SENTRY_TRACING__ that does remove tracing code webpack.treeshake.removeTracing sets this flag, but it currently works only with webpack. I have a fix in #24818 for it.

Until that is released, you can set the flag yourself:

const nextConfig: NextConfig = {
  compiler: {
    // Must be the boolean `false`, not the string 'false'. Turbopack injects strings as string literals.
    define: { __SENTRY_TRACING__: false as unknown as string },
  },
};

That being said, be aware that even with tracesSampleRate: 0 the SDK still links frontend errors to backend traces. It continues backend traces and handles sentry-trace/baggage headers to request. That code is part of the tracing code, so removing that also breaks these traces.

Errors are captured, but a frontend error will no longer show in the same traces as a backend request. If you don't need that, it's fine to set the flag to strip it out.