Change Request: Consider exporting config with all rules enabled

[SimonSchick]

eslint-plugin-n version

latest

What problem do you want to solve?

It tends to be hard to follow new best practices as they are implemented and not all end up in recommended.
Changes to recommended after often considered breaking, some people (including myself), prefer to opt into all eslint rules available and opt-out of the ones that are undesirable.

What do you think is the correct solution?

Export a config with all rules enabled and let the consumer opt-out.

Prior art:

typescript-eslint and eslint-plugin-unicorn export an all variant.

Participation

• I am willing to submit a pull request for this change.

Additional comments

I assume filing a PR for this would be relatively straight forward, there may be some differing opinions on individual rule configs though.

[aladdin-add]

I definitely like the idea of having a configuration that enables all rules, and I understand the desire to stay on top of best practices by opting out of specific rules rather than opting in.

However, eslint-plugin-n has a slight nuance to consider: some rules are specifically designed for ESM (ECMAScript Modules), while others are more suitable for CommonJS environments, and vice-versa. This means that an "all rules" approach might not be universally applicable.

To accommodate this, I'm wondering if we should perhaps consider exporting two all-encompassing configurations: all-script for CommonJS-centric projects and all-module for ESM-based projects. This way, we could ensure that users are getting all the relevant rules for their environment without any potential conflicts or rules that don't apply.

What do you think about that approach? I'm happy to discuss this further, and I'm excited to see a PR come through if you're still on board with this. Let me know your thoughts!

[SimonSchick]

This sounds perfectly reasonable/compatible given the pre-existing setup.

Do you think extending the respective recommended sets is a good approach? I can probably do this tomorrow since I have some time-off :)

[aladdin-add]

the recommended config was generated based meta.docs.recommended, e.g:

eslint-plugin-n/lib/rules/callback-return.js

Line 13 in 6aee9f2

recommended: false,

I like to add a new metadata to all the rules, so the config can be auto-fenterated too. maybe tags or category?

[SimonSchick]

I see that you already started on this so I assume I can hold off on this, ty!

[voxpelli]

I'm 👎 on this because it would have the addition of new rules become a breaking change for its users – and if one avoids the breaking change by not adding new rules to it in minor releases, then it's an all that doesn't include all rules

[SimonSchick]

https://github.com/eslint/eslint/tree/main/packages/js#eslint-javascript-plugin (eg. @eslint/js) also has an all variant, and this is core eslint.

The point of all it to automatically expose the user to all new rules, the fact that these are 'breaking changes' is expected.

Does it violate semver? Maybe? Kind of but not really? If the docs clearly state all is considered unstable in minor releases than this should be sufficient and not be considered breaking.

This is about practicality vs. correctness, some developers want to be on the bleeding edge w/out manually having to track each new eslint rule that is added

[aladdin-add]

Yes, eslint's versioning policy is that new rules added to recommended are MAJOR updates, but all is not - new rules may be added in non-major:

https://github.com/eslint/eslint?tab=readme-ov-file#semantic-versioning-policy

maybe we should document it somewhere: it's likely to break your build in non-majors; so use at your own risks.

[voxpelli]

@aladdin-add I see no mention of eslint:all there, only of eslint:recommended

I would like the name to indicate that this may happen in a non-major release:

is updated and may result in new linting errors (e.g., rule additions, most rule option updates).

Eg unstable-all, canary-all or something like that.

And ESLint should document a policy for eslint:all @nzakas

[SimonSchick]

See eslint/eslint#19318