Reading that field is closer to flipping a switch than turning a dial. The writeup's explanation is that SWC sorts every browserslist target into one of two buckets: legacy, meaning no support for native ES modules, where IE11 lands, and modern, which starts around Chrome 61, Safari 11 and Firefox 60, so anything from 2017 onward [7]. Chrome 139 sits 78 major versions above that floor [12]. The two Chrome targets tested are 23 versions apart [13]. Both live deep inside the same bucket, so the compiler had nothing to distinguish. It read two different fields and, judging by the output, took the same single fact from each [4].
Rewriting syntax and supplying missing builtins are two separate jobs in a build. Here the first followed the target and the second did not [5][6], which makes the browserslist array an instruction to the syntax pass and to nothing else in the JS pipeline. That is why the line in package.json reads as reassurance. It records a belief about which browsers you support, and the emitted JS is not where that belief gets tested.
For the two-bucket result to transfer to your repo, several things have to hold. The compared code is a single exported function exercising features dated ES2021 through ES2026 [10], built by Next.js 16, and in the modern builds the diffed snippet sits inside an onClick handler [15]. If your oldest supported browser is anywhere past native module support, that is the tested case, and the writeup's claim is that you should expect no difference in emitted JS syntax at all [8]. If it is below that line, you are in the legacy bucket, and the only sample here is IE11.
The reported results cover the emitted JS chunks. The same three projects also ship eslint-plugin-compat and a postcss.config.js with postcss-preset-env, installed specifically to check whether the tooling that consumes browserslist acts on it [9], and no verdict on those appears in the diff as published [14]. So treat this as a finding about JS syntax, not about CSS prefixing or lint coverage. All three projects are on GitHub [11], which is the part that makes it checkable rather than quotable.
The practical read is narrow and useful. If your floor is inside the modern bucket, tightening that array by Chrome version will not move a byte of your JS syntax, and the only lever that moves it is crossing the module-support line [8]. Cross it and you get syntax downleveling; the runtime builtins the ES5 output still calls are yours to supply [6].
