core-js-compat loose mode

[devongovett]

I was compiling some code with babel-preset-env, using the useBuiltins: 'usage' option and esmodules: true target. I noticed that I was getting the promise polyfill even though all modules supporting browsers support promises natively. I found several issues on this repo about that, e.g. #565. The reason on that one seems to be to do with unhandled promise rejection tracking not being supported cross browser, which is a bit different from Promises being supported at all I think.

Some other features have super aggressive targets as well, e.g. array.prototype.map set to Chrome 51. Seems pretty clear that that has existed natively for many years before that.

I understand that core-js is going for 100% spec compatibility and wants to work around edge case browser bugs, but sometimes that isn't necessary for certain projects. I was wondering if something like babel's loose mode could be supported for code-js-compat, with baselines set lower for the targets, not based on browser bugs but based on support. This would result in a much smaller amount of polyfill code being needed most of the time as native support for most ES features is pretty good these days.

Thoughts?

[zloirock]

I'm thinking about a not so strict version of core-js many years. I'll think about it. However, it requires a more complex approach.

[devongovett]

Let me know if there is anything I can do to help implement it. I think a good place to start would be a version of the core-js-compat data based on caniuse-db and compat-table, which should reduce the amount of polyfills that are needed for modern browser targets.

Another one I just came across: web.url is set to Chrome 63 in core-js-compat, vs 32 in caniuse. That causes ~100kb of extra polyfills to be added. Would be useful to know the reasons for these higher targets in core-js-compat. Is it just a matter of running the tests against some older browsers?

[devongovett]

btw, we're planning on enabling babel's useBuiltins: 'usage' option by default in Parcel 2 with core-js 3. Ideally this wouldn't cause large polyfills to be included where not needed (e.g. promise polyfill with esmodule target). So I'm happy to help out wherever needed.

[zloirock]

caniuse-db and compat-table can't be used for this case for many reasons, I explained it many times. Makes sence just simplify some test for the loose version of core-js-compat. Anyway, efficient work on it requires some architectural changes, so if it will be done, it will be done not right now.

[zloirock]

After much thought and experiments, I think that a loose version of core-js and / or core-js-compat is a bad idea - it's too dangerous.

Unlike babel which can transpile the project without dependencies, global core-js polyfills installed... globally and your dependencies will also use it. You could say to your team not to use some specific behavior - but you can't say it to thousands of developers who made your dependencies - and they use this behavior. I was able to verify this when I experiment with it.

babel provides tens plugins, but core-js provides hundreds of polyfills - it's too problematically remember all possible limitations which they could contain. It's OK for specialists, but not for usual developers.

You can manually configure the level of aggressiveness if you are sure that it's fine, you can exclude injecting of specified module - but creating something like loose mode will create temptation, which will cause a huge number of problems.

So it's better to solve it on the configurable level of aggressiveness and related APIs side. Sure, it requires improvement or reworking, but it's another issue.