stackoverflow.com, as data

3. **Only then, the target/ecmaVersion.** If the loader runs and a config is found, check that `targets` is not so modern that `??` is intentionally kept, and on webpack 4 raise `module.parser.javascript.ecmaVersion` or upgrade.## Reliable way to confirm the loader processed the fileTwo checks that give a definitive answer rather than a guess.**A. Grep the emitted bundle for the operator.** Build with `mode: 'development'`, `devtool: false`, then:I verified the discriminator holds: the raw source contains `??`, and the same source through `preset-env` with a legacy target does not. So **if `??` survives into the bundle, no transpiler touched that code** — you have a coverage problem, not a target problem. (Search for the operator specifically; do not eyeball minified output.)**B. Ask Babel directly what it would do with that exact file.** This bypasses webpack entirely and tells you whether config resolution works for that path:`npx babel --filename src/path/to/file.js src/path/to/file.jsIf that prints `??` back at you, Babel found no applicable config for that path — check `.babelrc` scope and `babel.config.json` placement. If it prints the `!== null && !== void 0` form, Babel is fine and the problem is the loader rule not matching in webpack.**C. Make loader coverage observable.** Temporarily add to the `babel-loader` rule:and run `webpack --stats-modules-space 999 --stats detailed`, then confirm the failing module lists `babel-loader` in its build chain. A module that shows no loaders is your answer.## On fixing the toolchain rather than the codeYour instinct is right — do not rewrite the operators. The two durable fixes, in order of preference:* Narrow the exclusion instead of blanket-excluding `node_modules`, so dependencies shipping modern syntax get transpiled: