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.