How to confirm that manual tree shaking variables are taking full effect?

[scameron]

I recently came across this page that talks about tree shaking in Sentry:
https://docs.sentry.io/platforms/javascript/configuration/tree-shaking/

I'm using Webpack with Sentry 8.55.0 and I tried to set the recommended variables in my build, as it shows on the page:

    new webpack.DefinePlugin({
      __SENTRY_DEBUG__: false,
      __SENTRY_TRACING__: false,
      __RRWEB_EXCLUDE_IFRAME__: true,
      __RRWEB_EXCLUDE_SHADOW_DOM__: true,
      __SENTRY_EXCLUDE_REPLAY_WORKER__: true,
    }),
    // ... other plugins

But I don't see almost any difference in the build output. What should I look for to validate that these variables are taking effect? Should entire internal Sentry modules get removed from the build?

One thing I should mention is that I've confirmed that automatic tree shaking is already working. Interestingly, when I do this:

import * as SentryClient from "@sentry/browser"

I see some tree shaking taking place. A bunch of Sentry modules now appear in 0 chunks in my build (as compared with using CJS require("@sentry/browser" where there is no tree shaking at all.

But when I change it to explicit import only the specific functions I'm calling, like this:

import {close, endSession, init, startSession, captureSession, getCurrentScope} from "@sentry/browser"

There's way, way more tree shaking that happens. A huge number of Sentry modules are removed from the build when I do this. So clearly Webpack does a much better job if you are explicit about what is being imported.

I'm wondering if that is already shaking out the modules that would be removed by the manual shaking using the DefinePlugin variables. Or is there more that can be done?

If there was some way to know which modules should be removed with those variables, I can validate that as much tree shaking as possible is taking effect.

Thanks!

Best regards,
Scott

[MILLERMARRU]

Your instinct that automatic tree-shaking is doing most of the heavy lifting is correct, and it's worth separating what these two mechanisms are actually shaking.

The DefinePlugin variables (__SENTRY_DEBUG__, __SENTRY_TRACING__, etc.) don't remove anything by themselves, they turn internal if (__SENTRY_DEBUG__) { ... }-style branches inside Sentry's own source into dead code (if (false) { ... }). That dead branch only actually disappears from your bundle during minification, when Terser (or whatever minifier Webpack is using) runs its own dead-code elimination pass over the now-if (false) blocks. So checking the raw, unminified build output won't show a difference, these flags are invisible until the minify step runs.

To actually verify they took effect: build for production (minified) and grep the final bundle for the literal identifier strings:

grep -c "__SENTRY_DEBUG__\|__SENTRY_TRACING__" dist/main.js

If the DefinePlugin substitution worked, that should return 0, the identifiers get replaced with the literal false before minification runs, so they shouldn't survive into the output at all. If you still see them, the DefinePlugin isn't matching (common causes: it's defined after another plugin that already processed the relevant files, or a version/casing mismatch between what your Sentry SDK version checks internally and what the docs page currently documents).

On your explicit-import finding: that's a separate and complementary mechanism, not evidence the DefinePlugin flags are redundant. Wildcard import * as Sentry from "@sentry/browser" still lets Webpack shake unused named exports at the module boundary, but explicit named imports (import { init, captureException }) give it a much easier per-export dependency graph to reason about, especially across Sentry's internal re-exports, so more whole modules become provably unreachable and get dropped entirely. The DefinePlugin flags are shaking dead branches inside modules you do import (debug logging, tracing internals), while your import style change is shaking out modules you don't need to import in the first place. Both are worth keeping, they're not overlapping optimizations.