Allow-listing syntax rules, like is already possible for polyfills

[niklaas]

Is there a way to whitelist any rule i.e., not only the ones there are polyfills for? In my use case, I would like the plugin to enforce according the browserslist but whitelist the no-rest-spread-properties rule:

https://github.com/robatwilliams/es-compat/blob/ca1078035c5bcb22741a71e4b0f93fd567120adc/packages/eslint-plugin-ecmascript-compat/lib/features/es2018.js#L16-L22

[robatwilliams]

Not at the moment. What do you need this for?

[niklaas]

Not at the moment. What do you need this for?

I just joined a codebase that's a Ruby-React-Angular creature with a custom build. I fell into the trap of adding a regular expression look-behind causing a regression because some of the older browser versions we want to support don't support that feature.

Since the browsers we want to support are documented well in the browserslist file, I came across this repository, adding the recommended rules accordingly. I now get my look-behind flagged but also a lot of other false positives that are actually dealt with by the build system.

Since I cannot whitelist any rule, I had to circumvent the false positives by using the eslint-plugin-es-x directly. However, I would prefer using this plugin instead since it wouldn't require me to remember to update the rules myself as soon as we change the browserslist.

Does that make sense? Why would you allow to whitelist rules there are polyfills for only?

[robatwilliams]

but also a lot of other false positives that are actually dealt with by the build system

In this case I recommend you lint your build output rather than your source code. Linting it with just this plugin and no other rules.

I had documented some example usages here but you have brought up a new one I will document: using the plugin to check that the transpiler configuration is adequate for the supported browsers.

Why would you allow to whitelist rules there are polyfills for only?

Polyfills are compatible with all browsers, so can be used to uplift supported features. Syntax (like in your example) must be transpiled or it'll cause a parsing error in the browser - there is no usefulness I see in being able to list these as exceptions; I envisage that for your purpose you lint the build output.

[niklaas]

In this case I recommend you lint your build output rather than your source code. Linting it with just this plugin and no other rules.

Ah. That's an interesting solution I haven't thought of! I think it does come with one trade-off though: The feedback loop for the developers is shorter because they won't see errors lighting up in their IDEs while coding. They will only see them when they light up in the CI/CD checks.

Anyway, linting the final build seems the best way to ensure that the shipped code doesn't contain any unsupported features. Who knows what the build system does to the code when it's transpiled? 👍🏼

I think we'll go with a two-gate set-up: First, we use eslint-plugin-es-x to flag particular rules while coding; and, second, we use eslint-plugin-ecmascript-compat to check the compiled code.

Thanks for sharing your thoughts!