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
It is a common practice now to run builds several times, at least once for "older" browsers and again for "modern" browsers, with different sets of polyfills. This is IMO not the right way or the right stage in the build/load process to hande feature detection and polyfilling. IMO it should happen entirely at runtime.
The reason is probably that the babel-loader generates code which "hard-wires" all polyfills with require().
Would it be possible to wrap these in feature tests and loading them only conditionally, with a mechanism like dynamic requires?
(I know, the Dynamic Imports might night to be polyfilled themselves and hence be the only exception to the general approach.)
I've looked at the customize option of the babel-loader but found no documentation on the actual customization options, and the behaviour that was implemented in the webpack example seems to receive ready-made code from babel inside result.code, whereas the result.ast (which might be easier to extend with the desired behavour) is null.
The text was updated successfully, but these errors were encountered:
It is a common practice now to run builds several times, at least once for "older" browsers and again for "modern" browsers, with different sets of polyfills. This is IMO not the right way or the right stage in the build/load process to hande feature detection and polyfilling. IMO it should happen entirely at runtime.
There seems to be no easy solution to do this with the common babel / babel-loader setup.
The reason is probably that the babel-loader generates code which "hard-wires" all polyfills with
require()
.Would it be possible to wrap these in feature tests and loading them only conditionally, with a mechanism like dynamic requires?
(I know, the Dynamic Imports might night to be polyfilled themselves and hence be the only exception to the general approach.)
I've looked at the
customize
option of the babel-loader but found no documentation on the actual customization options, and the behaviour that was implemented in the webpack example seems to receive ready-made code from babel insideresult.code
, whereas theresult.ast
(which might be easier to extend with the desired behavour) isnull
.The text was updated successfully, but these errors were encountered: