babel-preset-env: bump esmodule browserlist to Safari 11#10225
babel-preset-env: bump esmodule browserlist to Safari 11#10225connorjclark wants to merge 3 commits intobabel:masterfrom
Conversation
[ios_saf](https://github.com/Fyrd/caniuse/blob/bed4faadcea2ec7719c5f43167c0e2dace892be7/features-json/es6-module.json#L318) and [safari](https://github.com/Fyrd/caniuse/blob/master/features-json/es6-module.json#L239) do not support the `nomodule` attribute. It is common to use `esmodules: true` to split a build into two bundles (one containing fewer polyfills and transformed code - intended for newer browsers - and the other including more code to make old browsers happy), and `nomodule` is critical for that. I suggest bumping these browserlist constraints to Safari 11, which does support `nomodule`. To support these older Safari versions, a few big-cost transforms and polyfills must be added (list comes from GoogleChrome/web.dev#965). Bumping to 11 will remove all of these: ``` // transforms transform-template-literals { "ios":"10.3", "safari":"10.1" } transform-unicode-regex { "ios":"10.3", "safari":"10.1" } transform-async-to-generator { "ios":"10.3", "safari":"10.1" } // polyfills es.array.reverse { "ios":"10.3", "safari":"10.1" } es.array-buffer.constructor { "ios":"10.3", "safari":"10.1" } es.array-buffer.slice { "ios":"10.3", "safari":"10.1" } es.number.parse-float { "ios":"10.3", "safari":"10.1" } es.string.pad-end { "ios":"10.3", "safari":"10.1" } es.string.pad-start { "ios":"10.3", "safari":"10.1" } es.string.trim { "ios":"10.3", "safari":"10.1" } es.typed-array.float32-array { "ios":"10.3", "safari":"10.1" } es.typed-array.float64-array { "ios":"10.3", "safari":"10.1" } es.typed-array.int8-array { "ios":"10.3", "safari":"10.1" } es.typed-array.int16-array { "ios":"10.3", "safari":"10.1" } es.typed-array.int32-array { "ios":"10.3", "safari":"10.1" } es.typed-array.uint8-array { "ios":"10.3", "safari":"10.1" } es.typed-array.uint8-clamped-array { "ios":"10.3", "safari":"10.1" } es.typed-array.uint16-array { "ios":"10.3", "safari":"10.1" } es.typed-array.uint32-array { "ios":"10.3", "safari":"10.1" } es.typed-array.from { "ios":"10.3", "safari":"10.1" } es.typed-array.of { "ios":"10.3", "safari":"10.1" } ``` (Note: Will checkout the source code shortly and edit the file that generates this data https://github.com/babel/babel/blob/9febf6388233c3d23d4fa9deca5ca8f682567573/packages/babel-preset-env/scripts/build-modules-support.js#L20)
|
I thought I'd drop by here to suggest an additional part of this change: currently folks implementing Using the same |
|
Looks like these data files moved to https://github.com/babel/babel/blob/master/packages/babel-compat-data/data/native-modules.json @existentialism it seems your #10742 removes I'm not 100% caught up on the interplay w/ |
|
@connorjclark yes, these are directly covered by |
|
I don't have Safari to test, but if |
Oh, that's not the issue. The babel output when My take is that Safari 10.1 shouldn't be considered as supporting esmodules because it lacks That said, based on @developit's comment the |
|
One thing to clarify: I beleive Mobile Safari 10.1 supports |
ios_saf 10.3 and safari 10.1 do not support the
nomoduleattribute, so they should not be the minimum constraints whenesmodules: true.It is common to use
esmodules: trueto split a build into two bundles (one containing fewer polyfills and transformed code - intended for newer browsers - and the other including more code to make old browsers happy), andnomoduleis critical for that. I suggest bumping these browserlist constraints to Safari 11, which does supportnomodule.To support these older Safari versions, a few big-cost transforms must be added (list comes from my repro here: https://github.com/connorjclark/babel-esmodule-preset/tree/826e1c83faaa8a62f473179a08f467e575825c3e/src-esmodule). Bumping to 11 will remove all of these:
The
async-to-generatortransform is especially bad - adds lots of code that is slower than native async/await, even though all browsers that properly support es6 modules also support async/await.Note @wardpeet originally pointed out that this "build for modern browsers only" pattern doesn't really cut the mustard anymore - there are browsers 3 years old that support modules. However, these changes will at least cut some cruft for those still using this pattern.