should throw an error when disabling a non-existent rule

[aladdin-add]

Tell us about your environment

• **ESLint Version:**master
• Node Version:
• npm Version:

What parser (default, Babel-ESLint, etc.) are you using?
default

What did you do? Please include the actual source code causing the issue.

/* eslint foo: 0 */

// edit: or in a config file
{
  "rules": { "foo": 0}
}

What did you expect to happen?
throw an error, since there is no rule named foo.
What actually happened? Please include the actual, raw output from ESLint.
no error thrown.

[not-an-aardvark]

I can't reproduce this in the demo:

[aladdin-add]

interesting! seems only happen when disabling a non-existent rule.(same issue in config file)

[not-an-aardvark]

Does this also happen in a config file?

{
  "rules": {
    "foo": 0
  }
}

[aladdin-add]

yes, I guess it might be unexpected.

[not-an-aardvark]

This might be caused by #7690. I agree that reporting an error nonexistent rules might be a good idea.

Also related: #9373

[aladdin-add]

seems we are missing this issue, hopefully it can be fixed in eslint v5, since it would be a breaking change.

friendly ping @not-an-aardvark

[nzakas]

This seems like a nasty bug that we should fix with the next major release.

[not-an-aardvark]

As a minor note for whoever implements this: I think the invalid comment should be reported as a linting problem, not by throwing an error. In general we've been trying to preserve the invariant that issues with the source text shouldn't cause any errors to be thrown, since this prevents integrations from crashing if the integrations are supposed to handle arbitrary text from the user. (For example, see #9819 and eslint/archive-website#413.)

As another minor note, we've generally been using Projects rather than Milestones to track changes for major releases -- for example, I just added this issue to the v6.0.0 project.

[nzakas]

Ah gotcha, thanks for the heads up about projects.

…

On Wed, Oct 24, 2018 at 10:12 AM Teddy Katz ***@***.***> wrote: As a minor note for whoever implements this: I think the invalid comment should be reported as a linting problem, not by throwing an error. In general we've been trying to preserve the invariant that issues with the source text shouldn't cause any errors to be thrown, since this prevents integrations from crashing if the integrations are supposed to handle arbitrary text from the user. (For example, see #9819 <#9819> and eslint/archive-website#413 <eslint/archive-website#413>.) As another minor note, we've generally been using Projects rather than Milestones to track changes for major releases -- for example, I just added this issue to the v6.0.0 project <https://github.com/eslint/eslint/projects/5>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9505 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkrjbX7o00996Swq2hL54Ru3ZSVhTks5uoJ-EgaJpZM4QDLyS> .

--

______________________________ Nicholas C. Zakas @SlickNet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>

[sstern6]

Would like to take this on, though I have a few questions.

But before i get into it, @aladdin-add have you started working on it?

[kaicataldo]

@sstern6 Though you can feel free to make a PR, we're most likely quite a ways out from our next major release. Since this is a breaking change, we wouldn't be able to merge it until we start working on that release in earnest. My recommendation would be to hold off for now until that process starts.

[sstern6]

thanks @kaicataldo Ill hold off. Plenty of other stuff I can get done.

[sstern6]

@kaicataldo because were on 5.9.0, should we start considering how to handle this for the major release?

[ilyavolodin]

@ljharb Would a warning for non-existing rule be an issue for you? As in, if you disabled a rule in AirBnB that was added in 6.1 and somebody runs your config in 6.0, it would display a warning saying that the rule doesn't exist.

[ljharb]

As long as there was a way to silence the warning (separate from --quiet, but I’d expect quiet to silence them too), that seems tolerable - but what would be better is a way to do that directly in the config, like “i know this might not be a rule but hush, i know what I’m doing”.

[btmills]

We discussed this in today's TSC meeting, and the conclusion was that we should be safe throwing an error if someone disables a non-existent rule in a configuration comment in 6.0.0. We'll leave configuration files (and plugins) alone for this version and see if there's a solution that works for end users and plugin authors to be defined later.

[ljharb]

That sounds fine for my use cases, thanks for considering them!

[aladdin-add]

working on this.