\"The build succeeded\" and \"the code was tree-shaken\" are unrelated claims. A production build with zero errors can still ship a fully dead, unreferenced module byte-for-byte, because tree-shaking is not a guaranteed pass — it is a conditional static-analysis optimization that silently no-ops the moment it hits a CJS require, a missing or wrong sideEffects field, a barrel-file re-export, or a development-mode build. This skill treats \"eliminated\" as a claim that must be proven from bundle-analyzer output bytes and module lists, before and after, in a production build — never inferred from build success, and never inferred from a sideEffects: false change applied without reading the target module for real side effects first, since that specific mistake causes silent runtime breakage (dropped polyfills, dropped CSS injection, dropped security-relevant initialization), not just a size regression.
Use this skill when the user asks to:
\nsideEffects field in package.json for an app or a library the user is authoring,sideEffects: false change either had no effect or broke something at runtime.bundle-budget-code-splitting-review first to establish the numeric budget and rank contributors; hand off here once a specific module is suspected of being fully unused rather than merely heavy.bundle-budget-code-splitting-review owns it.core-web-vitals-triage first, return here once dead code is the named suspect.Tree-shaking configuration surface differs by bundler and has shifted across majors (Rolldown replacing Rollup inside Vite 7+, webpack's sideEffects/usedExports interaction, Rollup's treeshake preset system). Do not prescribe a fix from memorized training data.
ToolSearch with query \"context7\" (or \"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs\") to load the Context7 tools if not already loaded this session.mcp__Context7__resolve-library-id for the bundler actually installed in the project (webpack, Rollup, or Vite/Rolldown) before prescribing any sideEffects or treeshake configuration — do not assume the bundler from the framework name alone.mcp__Context7__query-docs for the specific mechanism in question — e.g. \"sideEffects array vs boolean\", \"treeshake.moduleSideEffects options\", \"production mode requirement for usedExports\" — before ruling on it. Do this per review; do not reuse a prior session's memory of bundler internals.mode: 'production' (or optimization.usedExports explicitly enabled) to take visible effect; sideEffects: false in package.json additionally requires optimization.providedExports (on by default in production mode) to let webpack drop unused-export modules; a module with real side effects (e.g. CSS imports) must be listed explicitly, e.g. \"sideEffects\": [\"**/*.css\"], or that side effect is silently dropped.treeshake accepts false, a preset ('smallest' | 'safest' | 'recommended'), or a fine-grained object — moduleSideEffects (boolean, 'no-external', a string array, or a predicate function) and propertyReadSideEffects are the two options most often responsible for either under- or over-aggressive elimination.build.rollupOptions is now an alias for build.rolldownOptions and is deprecated in favor of it — verify which option surface the installed Vite major actually documents before prescribing config keys.official_docs and mark the claim documentation-based (Context7 unavailable) rather than presenting it as freshly verified.package.json field that no queried source confirms.exports/module with an import condition vs. a main/require-only CJS entry) — do not infer format from the package's popularity or age. CJS defeats static tree-shaking analysis regardless of bundler, and is the most common silent cause of \"unused code that won't go away.\"sideEffects in both the app's own package.json and the suspect dependency's package.json. A missing field or sideEffects: true tells the bundler to assume every import has a side effect and keep it — this is often correct behavior being mistaken for a bug.sideEffects: false on any module, read that module for top-level side-effecting code — global polyfills, CSS-in-JS injection, prototype patching, analytics auto-init, CSP nonce injection, sanitizer initialization. A false sideEffects: false claim is a correctness bug that ships silently; it will not show up as a build error.import * as utils from './utils', or a package index.js that re-exports everything) in the app's own code before blaming the dependency — this is a common tree-shaking blocker that has nothing to do with the dependency's configuration.sideEffects: false change, require a runtime smoke test of the affected surface, not just a rebuild — dropped initialization code fails at runtime, not at build time.Load these only when needed:
\nsideEffects field in package.json (webpack's flag semantics and the production-mode requirement).treeshake.moduleSideEffects, propertyReadSideEffects, or preset-level configuration.Return, at minimum:
\nsideEffects field state for both the app and the suspect dependency, cited from the actual package.json content read,sideEffects: false is newly applied.