Certain Polyfill modules aren't supported in checks

[ScubaDaniel]

When I try to check for compatibility for certain modules, the compat function doesn't return any information:

let {compat} = require("core-js-compat");

compat({target: "ie 9", modules: ["web.set-timeout"]});

// {"list":[],"targets":{}}

According to the table, this polyfill module is required:

This seems to be the case for the following modules:

  'es.map.constructor',
  'es.object.get-own-property-symbols',
  'es.set.constructor',
  'es.symbol.constructor',
  'es.symbol.for',
  'es.symbol.key-for',
  'es.weak-map.constructor',
  'es.weak-set.constructor',
  'web.set-interval',
  'web.set-timeout'

[zloirock]

Now, in the current stage of refactoring of core-js, some modules split into some parts. core-js@3 contains module web.timers that is split into web.set-timeout and web.set-interval. In core-js@4, web.timers will be replaced by web.set-timeout and web.set-interval. However, current tooling, including core-js-compat (the package, not the testing tools) and preset-env, does not know anything about those modules, only about web.timers. The same related to the rest modules from your list.

[zloirock]

The full list of such modules you could find here.

[ScubaDaniel]

@zloirock I'm not sure I understand.

I'm using the preset-env from Babel to generate polyfill from my source code based on usage. Then I'm taking the polyfill automatically provided and analyzing the compatibility for each module automatically added based on usage since core-js doesn't seem to tell you which browsers need the polyfill.

On a related note, it seems like this should be fixed, as documentation seems to suggest it work when using a browserlist query instead. I had to custom write a solution to call compat for each of our target browsers to analyze what polyfill is needed for each version.

How exactly am I supposed to know the compatibility for the modules for web.set-timeout then? Core-js is automatically providing that for our bundle and I'm using the core-js-compat to analyze them. Why would these not be in sync at the same versions of core-js/core-js-compat? This doesn't make any sense to me.

[ScubaDaniel]

I'm using core-js@3 with Babel's preset-env. Why would it include web.set-timeout if you're not using it?

However, current tooling, including core-js-compat (the package, not the testing tools) and preset-env, does not know anything about those modules, only about web.timers.

That's not correct. preset-env is already providing me web.set-timeout using core-js version 3.23.5.

Again, how am I supposed to use this plugin to check for compatibility on that module at all then? That seems like a bug, as you shouldn't remove the ability to check for that module core-js still provides. Just because you're moving the category in the future doesn't mean I still don't need to validate how it was used in core-js already...

This doesn't make sense.

[zloirock]

It seems you still don't understand how it works. Babel's preset-env does not know anything about web.set-timeout and does not include it. It's an internal module. However, if you use setTimeout, in IE9-, preset-env include web.timers that internally contains web.set-timeout and contain the proper compat data.

[ScubaDaniel]

I think I understand, but it doesn't really help with what I need.

To be clear, the reason I have to custom make a solution for this is because core-js-compat takes a list of minimum targets, yet the targets response only lists the minimum target for compatibility. It would be SO MUCH more useful if it actually gave you information on what versions of which browsers actually need the polyfill.

I suppose I can ignore the list like you're suggesting - it just seems like this is going to be confusing for many folks like myself.

[zloirock]

Sorry, but you just pass an invalid (internal) module to the tool - so it's only your mistake.

web.set-timeout is not documented and is used only in internal tooling like the browser compat tests runner.

All that I can do in this case - throwing an error on invalid modules in core-js-compat that now interpreted as an empty namespace.

[ScubaDaniel]

Sorry, but you just pass an invalid (internal) module to the tool - so it's only your mistake.

Why are these under core-js/modules and not internals in that case? I'm filtering out every other internal just fine, but these are listed as modules the same as web.timers. If they are internals they shouldn't they be categorized as such until they're fully-fledged modules?

web.set-timeout is not documented and is used only in internal tooling like the browser compat tests runner.

It's literally listed under the table here and in the screenshot I provided: http://zloirock.github.io/core-js/compat/
How is that not documented and only used in internal tooling? That doesn't make sense. That's definitely public and confusing.

[zloirock]

Why are you looking in the folder, but not in the documentation? -) Not all modules from this folder are public. If for some reason you think otherwise - this is a delusion.

This table is an internal testing tool and visualization of collected compat data, but is not the list of available modules.

RTFM.

[ScubaDaniel]

Why are you looking in the folder, but not in the documentation?

Because of what I said earlier:

To be clear, the reason I have to custom make a solution for this is because core-js-compat takes a list of minimum targets, yet the targets response only lists the minimum target for compatibility. It would be SO MUCH more useful if it actually gave you information on what versions of which browsers actually need the polyfill.

I have to go through all our bundle contents and manually check compatibility for each browser and version combination because if I call compat with "ie > 9" it doesn't tell me what polyfills aren't needed by IE10-11. It only gives me a list of polyfills and lists "ie > 9" for every single one. It'd be great if the targets response actually told me which browser versions need the polyfills. The documentation suggests this is possible using a browserlist query, but it definitely doesn't work if you define minimum browser versions manually.

I used a bundle analyzer with webpack to get the files provided by preset-env, which is why I'm grabbing anything under core-js/modules.

[zloirock]

If you see in your bundle core-js/internals/is-object, you also pass it to core-js-compat? web.set-timeout at this moment is similar internal module. And they both have no public compat data since it's internal modules. The full list of available public modules you could find here. As I have already many times written, "grabbing anything under core-js/modules" is a wrong approach.