You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By using useBuiltIns: "usage", Babel will only inject polyfills for unsupported ECMAScript features (according to target browser version) but only if they are actually used in the input source code;
By using @babel/plugin-transform-runtime and setting its corejs option, Babel will inject ponyfills (which are "pure" and don't pollute the global scope) for every used ECMAScript feature supported by core-js. This is usually used by library authors.
@babel/plugin-transform-runtime does not support only polyfilling the features required by the target browser versions like @babel/preset-env does. This results in unnecessarily large bundles containing unused polyfills.
useBuiltIns and @babel/plugin-transform-runtime's corejs option are mutually exclusive. Now CLI selects to set the @babel/plugin-transform-runtime's corejs option to false, and use useBuiltIns with its corejs option. We don't care the pollutions when developing an application, but it's better bundle library without side effect(pollution). The pollution caused by the library may lead to weird problems, and it is difficult to locate the bug.
How to solve?
setting useBuiltIns: false, using @babel/plugin-transform-runtime and its corejs option to bundle library (but increasing bundle size)
Version
4.5.10
Reproduction link
https://github.com/fangbinwei/vue-cli-issue-lib-polyfill-pollution
Environment info
Steps to reproduce
Compare the results of IE11 and Chrome.
Promise.prototype.finally
is not a function in IE11.What is expected?
Polyfills are injected to library without global namespace pollution.
promise.finally
polyfill works in IE11.What is actually happening?
Check the README of the reproduction demo.
By using useBuiltIns: "usage", Babel will only inject polyfills for unsupported ECMAScript features (according to target browser version) but only if they are actually used in the input source code;
By using
@babel/plugin-transform-runtime
and setting itscorejs
option, Babel will inject ponyfills (which are "pure" and don't pollute the global scope) for every used ECMAScript feature supported by core-js. This is usually used by library authors.@babel/plugin-transform-runtime
does not support only polyfilling the features required by the target browser versions like@babel/preset-env
does. This results in unnecessarily large bundles containing unused polyfills.useBuiltIns
and@babel/plugin-transform-runtime's corejs option
are mutually exclusive. Now CLI selects to set the@babel/plugin-transform-runtime
's corejs option tofalse
, and useuseBuiltIns
with itscorejs
option. We don't care the pollutions when developing an application, but it's better bundle library without side effect(pollution). The pollution caused by the library may lead to weird problems, and it is difficult to locate the bug.How to solve?
setting
useBuiltIns: false
, using@babel/plugin-transform-runtime
and itscorejs
option to bundle library (but increasing bundle size)babel try to solve this problem by
babel-polyfills
, but it's experimental now. related issue: RFC: Rethink polyfilling story babel/babel#10008The text was updated successfully, but these errors were encountered: