According to #3994 it is possible to disable regenerator by specifying
"browserslist": {
"development": [
"last 1 Chrome version"
],
"production": [
....
}
This seems to work on my project files, but it still processes all packages in node_modules that use async and await (my packages). Is it possible to disable this for everything? Thanks!
Maybe it's just cached somewhere?
This was previously the case when we were in the alpha stages of 2.0. Currently as of 2.1.3, browserslist should only be applied to CSS stylesheets as described here. @babel/preset-env shouldn't be using your browserslist config as we've disabled it.
If you're using async/await in your application code i would imagine you should also see the generator output there as well regardless of your browserslist value.
Would it be possible to reinstate this feature? Being forced to use a transform that gives a massive speed hit and seriously hinders debug stepping in Chrome devtools in order to support a browser that I don't need to support means I'll be ejecting in every app I make.
@nmain that is shocking! 38times slower on Edge, just to have Internet Explorer 9 running, that's ... interesting to say the least. Thanks for pointing out the line @ianschmitz. time to hack is now.
Thankfully, it's not quite that bad, as you have to look at the baseline they're comparing against. For instance, in the case of generator, here's the "1x" speed code: (https://github.com/kpdecker/six-speed/blob/master/tests/generator/generator.es), and here's the es6 code, which, when transpiled in various ways, is used to populate the other rows: (https://github.com/kpdecker/six-speed/blob/master/tests/generator/generator.es6). The two do similar things. but aren't quite comparable. The real travesty is the "es6" column, which means that running that generator code native in Edge is 24x slower than running es5 code that does a similar thing. But, comparing 24x to 38x, means that running the es6 code transpiled is still almost twice as slow in Edge as running that same code natively.
The worst one is Chrome; because they've optimized generators and async stuff so much in the recent versions, the transpiles are much slower there relative to the native es6 versions.
@ianschmitz - Are you able to unlock #3994? It's locked but in its current state it's giving people (like me, @tomitrescak, @mrapogee, and likely many others) false hope about use of browserslist in current CRA builds.
Therefore, I'd like to add a comment to that issue to prevent more people from wasting time. I'd also like to link people to a canonical issue they can use to discuss, vote on, and/or share workarounds for removing async/await and other polyfills. Currently there are several dupe issues on this topic:
We should probably pick one of these to be the master issue and point the others there. Got a preference for which to make the master?
@justingrant sure thing!
Cool, thanks @ianschmitz. Do you have a preference for which of those three issues should be the "master" of this feature request?
Looks like #6198 is probably the most general and relevant for using browserslist with @babel/preset-env to accomplish what you guys are hoping for.
Cool. @ianschmitz you might want to close (edit: and lock!) this issue and also #3994 so we can coalesce future feedback into the master issue #6198.