Skip to content

Add all rules config #1543

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
akoidan opened this issue Nov 18, 2019 · 7 comments
Closed

Add all rules config #1543

akoidan opened this issue Nov 18, 2019 · 7 comments

Comments

@akoidan
Copy link

akoidan commented Nov 18, 2019

Some rules, e.g. no-relative-parent-imports are missing in default rule set. Lets create a config "plugin:import/all" that will include everything.

This config doesn't produce all linting rules:

{
  "extends": [
    "plugin:import/errors",
    "plugin:import/warnings",
  ]
@ljharb
Copy link
Member

ljharb commented Nov 18, 2019

That would make adding a rule always be a breaking change; it wouldn't be valuable to have such a config.

@ljharb ljharb closed this as completed Nov 18, 2019
@akoidan
Copy link
Author

akoidan commented Nov 18, 2019

@ljharb That's what most set of rules do.

  • They don't break anything
  • Noone forces you to use use allConfig you you bump the config every day like a crazy

@ljharb
Copy link
Member

ljharb commented Nov 18, 2019

@akoidan adding a new rule to any plugin's config is always semver-major - that's how everyone in the ecosystem does it.

Thus, an "all" config would also either not get new ones until the next major - just like "recommended" already does - or, would force a semver-major bump any time a rule is added.

@akoidan
Copy link
Author

akoidan commented Nov 26, 2019

Is it?

New rules come withing minor versions and it's totally ok, you can:

  • always disable a rule
  • you're not forced to use all config
  • you always have a lock file for fixed version if you don't care about lib updates, which you shouldn't be of.

@ljharb
Copy link
Member

ljharb commented Nov 26, 2019

Fair enough that eslint itself does it; you'll note the concerns in eslint/eslint#6248 :-) specifically, eslint/eslint#6248 (comment)

You only have a lockfile if you have one; apps should have them but libraries shouldn't. Generally speaking, the only valid response here to "it's a breaking change" is "you don't have to use it", which is true.

Can you explain why you want this?

@akoidan
Copy link
Author

akoidan commented Nov 26, 2019

@ljharb I want the most arrgessive rules for by configuration as possible. Most of the things that I find useful, e.g. no-named-as-default usually don't come in recommended config.

  • And I need to go via each rule and include it into config manually.
  • Or I wouldn't even know they they exist as I assume config would include everything.

It would be much easier (at least for me) if I could include all config and exclude rules which make me uncomfortable because they would warn in stoud instead of going via each rule and hardcode everything manually. And after I bump all config I wouldn't even know that some useful rule came out.

@ljharb
Copy link
Member

ljharb commented Nov 26, 2019

The most aggressive possible configuration won't necessarily match the defaults; some rules can only be manually configured for your project and have no reasonable defaults - it seems like you might want to do what I do with the airbnb config, and configure them yourself, but use eslint-find-rules in CI to warn you when new rules arrive that you haven't configured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants