core.js semver version seems wrong, only considers strict major version

[jquense]

Went to upgrade after #31 was released and noticed that the issue continued to persist. The reason is get-modules-list-for-target-version is being fed 3 for the version by default, which ignores 3.1, 3.2, etc. I tried a few semver-y things to be more inclusive but it seems core-js doesn't support those, so one needs to manually set 3.6 or whatever the latest is, which seems less than ideal.

[nicolo-ribaudo]

"latest" cannot be the default version because it would cause breaking changes whenever a new minor version of core-js is released (the plugin wouldn't be compatible with the previous version by default).
I can manually set the default to be 3.6, if that works.

[jquense]

breaking would be bad, it's not clear tho why it would break. shouldn't any minor version be compatible with previous ones for the major version?

[nicolo-ribaudo]

Let's suppose that core-js 3.6 doesn't support es.promise.finally, and that it is introduced by version 3.7.

If I have this code:

new Promise().finally();

the generated output might be something like this, which is perfectly compatible with core-js 3.6:

import "es.promise";

new Promise().finally();

Now, let's suppose that core-js 3.7 is released. If the plugin defaults to "latest core-js version", then it defaults to a version that supports es.promise.finally. The generated code would then be

import "es.promise";
import "es.promise.finally";

new Promise().finally();

However, this code will break if the user had "core-js": "3.6" in their package.json because it doesn't support es.promise.finally.

[jquense]

ah, right. That isn't great, tho maybe not much of a problem in practice as generally package mgmt sides on the latest compatible semver version. The other side of this is also mildly broken (which is how i got here). where i have the latest corejs installed but babel-polyfill was not polyfiling it. Practically this produces in the same sort of broken runtime time code, tho i'd suggest the later is more likely to happen than the former.

in any case, maybe this deserves a more prominent spot in the readme that you must match your local core-js version exactly or miss out on supported polyfills.

Could also have the plugin check if there are supported polyfills in a higher version and warn the user?

[nicolo-ribaudo]

I can throw an error if you don't explicitly set the version maybe?

Could also have the plugin check if there are supported polyfills in a higher version and warn the user?

That's a good idea!