Add no-unnecessary-polyfills rule

[Mesteery]

Fixes: #36

---

IssueHunt Summary

Referenced issues

This pull request has been submitted to:

• #36: Rule proposal: no-unnecessary-polyfills

---

[zloirock]

For core-js@3 / core-js-pure, use core-js-compat - @babel/compat-data is not the proper data source for them.

[Mesteery]

Is this what you suggested? @zloirock

[zloirock]

@Mesteery for core-js - yes, but not for the rest polyfills. I meant that you could use entries for the rest polyfills too. For example, you can get the list of features like

Object.keys(coreJsEntries).flatMap(it => (it.startsWith('core-js/actual/') && !/\/(virtual|instance)\//.test(it)) ? it.slice(15) : [])

and operate with them like with core-js entries.

[Mesteery]

Sorry, but I didn't quite understand that.

[zloirock]

core-js modules do not directly correspond to language features. Entry points - correspond. Many language features depend on some modules, like with Set example above. A module is an abstract part of a language feature polyfill.

For example, you have an import of string-at-polyfill. With your regex patterns, you can understand that it's an at method of String. However, core-js module for this feature is es.string.at-alternative - you can't directly rely on it. However, since you know that it's an at method of String, you can rely on core-js/actual/string/at data and you will see that this feature depends on es.string.at-alternative module - and check compact data for this module. If it depends on some modules - you can check all of them, like now it's done in the core-js case.

[Mesteery]

Like this 707f4f2?

[zloirock]

Yes, something like that.

[Mesteery]

PTAL @fisker

[fisker]

Sorry for the delay, I'll review ASAP.

[fisker]

Sorry for the long delay. Feel hard to review, I'll take another round later.

[fisker]

Not every package.json have engine field.

[Mesteery]

Indeed, that is in case the targets field is not defined in the config. If the engines field is also undefined, the plugin is not executed.

[fisker]

The tests are failing.

[Mesteery]

Fixed. The errors is due to STATIC_REQUIRE_SOURCE_SELECTOR (maybe i misused it, but it worked correctly with STATIC_REQUIRE_SELECTOR), and the Object.assign (. instead of #, in tests), there is no way to know if it is a static method or not... except hardcoding static methods.

[Mesteery]

Thanks you! Is it ready or i missed some changes?

[sindresorhus]

@Mesteery Bump

[Mesteery]

I'm sorry for all the delay, I was really busy. (btw, I don't know how to fix the markdown lint error)

I have a doubt about one thing, I'm not sure if corejs({targets}) supports SemVer syntax with targets = {node:'semver'}

[fisker]

I'm not sure if corejs({targets}) supports SemVer syntax with targets = {node:'semver'}

#1717 (comment)

[Mesteery]

If I understand you want node.engines to be core-js targets?

[sindresorhus]

Bump

[fisker]

I mean I don't know if core-js accept engines if not, translate to targets, other user input targets pass directly to core-js.

[Mesteery]

I apologize again for the delay. I've slightly refactored the code, and I passed engines directly to corejs targets if browserlist is not defined (and I've removed useBrowserlistFieldByDefault, as I think it would make more sense to always have engines as a last resort). However, I'm not sure that corejs correctly supports the semver syntax that can be used in engines.

[sindresorhus]

CI is failing