Which configuration takes precedence when both browserslist and explicit targets are defined in Babel preset-env?
0 reputation · 29 Feb 2020, 14:09 UTC
Babel's preset‑env resolves the set of supported runtime environments by merging targets from a browserslist configuration and an explicit targets option. When both are present, the precedence governing which source takes effect is not specified in the documentation, creating ambiguity for build pipelines that depend on consistent polyfill injection.
The resolved target set directly determines which core-js polyfills are included in the output; a shift in precedence can alter runtime support without modifying source code. Plugins such as @babel/plugin-transform-runtime rely on this resolution, and inconsistent target selection may cause polyfill omission or duplication across builds.
In the current release, an explicit targets entry in .babelrc appears to override a conflicting browserslist entry, but this behavior is not formally guaranteed across minor Babel 7.x versions or between CLI and API entry points. Which source takes precedence when browserslist and explicit targets conflict across Babel 7.x minor releases? How does the resolved target set influence polyfill inclusion for @babel/plugin-transform-runtime in mixed configuration scenarios? Is there a predictable method to determine the final target set without inspecting the preset‑env internal utilities?