-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Description
Feature Request
I'm super glad to see the esmodules
alias directly supported in preset-env
, but I have concerns that it will very soon become mostly useless.
While it's true that today most module-supporting browsers are generally modern, that won't be true a few years from now. For example, when Chrome 86 ships in two years, Chrome 61 will seem horribly old, but people using the esmodules
target will still be getting transpilations and polyfills applied for it.
Today the esmodules
target is kind of like a whitelist for any browsers greater than or equal to the minimum module-supporting browsers versions specified here. But it'd actually be much better as a blacklist that filters out any browsers that don't support modules.
To understand the difference, consider what I currently do on my blog:
{
targets: {
browsers: [
// The last two versions of each browser, excluding versions
// that don't support <script type="module">.
'last 2 Chrome versions', 'not Chrome < 60',
'last 2 Safari versions', 'not Safari < 10.1',
'last 2 iOS versions', 'not iOS < 10.3',
'last 2 Firefox versions', 'not Firefox < 60',
'last 2 Edge versions', 'not Edge < 16',
],
},
}
I'd like to see the esmodule
target work similarly. For example, I'd like to be able to do something like this:
{
targets: {
browsers: ['last 2 version, > 1%'],
esmodules: true,
},
}
And that would effectively turn my query into this:
{
targets: {
browsers: [
'last 2 version, > 1%',
'not Chrome < 60',
'not Safari < 10.1',
'not iOS < 10.3',
'not Firefox < 60',
'not Edge < 16',
'not Opera < 48',
],
},
}
This would allow me to specify my feature support exactly as I'm used to, but I'd be sure I wasn't getting any features not needed by browsers that work with <script type="module">
.
/cc @kristoferbaxter