core-js@3 adds es.promise when esmodules target is set to true

[wardpeet]

When using @babel/preset-env with core-js@2 it doesn't include es.promise when we set the target options to esmodules: true.

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage",
        "corejs": 2,
        "targets": {
          "esmodules": true
        }
      }
    ]
  ]
}

Core-js@2 target list:
https://github.com/babel/babel/blob/a596da28220b69df6265192d1ca788e6b9ca67aa/packages/babel-preset-env/data/corejs2-built-ins.json#L947-L957

When switching to corejs 3. es.promise is being added as a polyfill because it's browser compat is different from version 2. This makes esmodules=true pretty useless. It seems like promises are pretty flawed because of a bug in v8 but not sure why safari 11 is targetted. I wonder if we should lower it for the sake of keeping esmodules valuable. With es.promise set, no one is going to use the esmodules shorthand.

core-js/packages/core-js-compat/src/data.js

Lines 691 to 695 in b843714

	'es.promise': {
	// V8 6.6 has a serious bug
	chrome: '67', // '51',
	safari: '11.0',
	},

The buug in v8: https://bugs.chromium.org/p/chromium/issues/detail?id=830565

I think core-js should stick to compat tables and not care to much about browser bugs but that's just my opinion.

Another option might be to add an option to @babel/preset-env to disable checks for browser bugs. Whenever a new bug comes up we might need retarget these polyfills to chrome 75 and lots of browsers will get unecessary polyfills.

[zloirock]

Sorry, I do not completely understand your issue. What do you mean by "it doesn't include"?

It seems like es.promise is configured pretty high because of a bug in v8

I can say more: Promise polyfill required even for modern FF or Edge because they have not to support unhandled rejection tracking.

I think core-js should stick to compat tables and not care to much about browser bugs but that's just my opinion.

I'm one of compat-table maintainers and I can say that compat-table data is not enough for polyfilling.

[zloirock]

It looks like a duplicate of #446, #264, #221, #191, #178, etc.

[wardpeet]

I updated the above issue a bit but I think you're right. It's a duplicate indeed. This makes me to believe that we might need to update the usage property inside @babel/preset-env to only include it when these bugs are hit.

Thanks for the fast answer!

maybe add one of the issues to the compat json so you don't get this issue over and over 😛

[zloirock]

@babel/preset-env have expected behavior. If you don't need this polyfill in some cases, you can use exclude preset-env option and configure the level of aggressiveness on core-js side.

[zloirock]

maybe add one of the issues to the compat json so you don't get this issue over and over 😛

Feel free to add a PR -)

[wardpeet]

sweet, I thought it only worked for transforms!
Thanks a bunch!

Oh will definitly create a PR! 👍