Add option to ignore deprecated rules.

[Rob--W]

With #2920 and #1549, eslint will unconditionally print a warning when a deprecated rule is encountered. This patch still has a huge issue, which becomes apparent in the following scenario:

1. I have a .eslintrc file which extends a third-party .eslintrc
2. The third-party .eslintrc uses a deprecated rule.
3. I use tools (e.g. the syntastic plugin for Vim) that complain loudly whenever eslint reports an error or warning.

Ideally, every eslintrc in the chain would only use valid options. In the real world, this is not always the case. I could submit a patch to the third-party to fix their .eslintrc, but meanwhile my workflow is disturbed by the eslint warnings, because there is no way to disable deprecated rules *.

What I'm requesting is a way to disable deprecation warnings. E.g. any of the following:

• command-line flag
• new rule(s)
• do not warn about deprecated keys if the replacement has been set
• a way to disable inheritance of a rule (e.g. a special value 'no-inherit').

* currently, the only work-around is to define the deprecated rule in a rulesdir, which in turn imports the replacement (or is a no-op).

[ilyavolodin]

Have you tried running eslint with --quiet command line option? If it doesn't work, could you past command line output here please?

[Rob--W]

--quiet does not work.

Here is a minimal example:

$ echo 'var x' | eslint --stdin  --rule 'no-wrap-func: 2'

<text>
  1:1  error  Rule 'no-wrap-func' was removed and replaced by: no-extra-parens  no-wrap-func

Given the previous example, the obvious work-around could be using

$ echo 'var x' | eslint --stdin  --rule 'no-wrap-func: 0' --rule 'no-extra-parens: 2'

But that won't work if devs use different versions of eslint.

[IanVS]

What if we override the severity of all depreciation errors to warnings? Then the --quiet option would suppress them.

[Rob--W]

Changing errors to warnings is a step in the right direction, but still of no use if I don't disable warnings in my vim plugin.

Logic like if (has_ignore_deprecated and has_deprecated_rule and has_replacement) { /* silent */} else { warning } would be nice. The advantage of this over an all-suppressing flag is that it still helps devs to quickly migrate rules while maintaining backwards-compatibility in the rule definitions.

[ilyavolodin]

Sorry, maybe I'm not fully understanding what you are asking for, but what's stopping you from having your personal config (the one that has extends in it) override depreciated rules and set them all to 0? As far as I can tell from the code, that should stop them from sending errors/warnings about deprecation.

[IanVS]

Yes, that should work (setting the removed rules to 0) to prevent the messages.

[nzakas]

This is a temporary problem with the introduction of 1.0.0, so I don't think any change is necessary. You shouldn't be relying on 1.0.0-rc-1 in production right now.

You can revert to 0.24.1, which will still have all the rules you're looking for. Once 1.0.0 is final, there will be a one-time cost of updating configs, but we will never get there if we let people optionally hide these messages.

So I'd suggest reverting to 0.24.1 until the dependency has had time to upgrade.

Otherwise, setting those files to 0 in your config is the best way to go.

[Rob--W]

@ilyavolodin My "personal config that has extends" is checked in in a shared repository, so I thought that editing it and setting the rules to 0 would cause rules to be overlooked if others use an older versions of eslint. But it just occurred to me that these old versions would show a warning about an unknown rule, so that's not an issue any more.

@nzakas If we shouldn't be relying on 1.0.0-rc-1, why is that version published on npm and thus when npm install -g is used?

Setting all rules to 0 is a reasonable way to work around my problem, but another issue with this is that we eventually end up with bloated eslint configuration files. A new flag to check for deprecated/unknown keys would be nice. In particular, this new tool should also be able to report unknown/deprecated rules in parent eslintrc (so that removing deprecated_rule_name: 0 from my eslintrc does not reactivate the warning for the same shadowed rule in an ancestor eslintrc.

[ilyavolodin]

@Rob--W We released RC1 to gather feedback from the users. That's sort of a whole point of RC. We released it as latest, because we are still not at 1.0.0, so theoretically, you shouldn't really rely on this in production (although ESLint has been stable enough for a while).
As @nzakas mentioned this is a temporary situation until 1.0.0 is released, after 1.0.0 we will be much more guarded about removing and deprecating rules.

[nzakas]

@Rob--W yeah, I messed up by making it work with @latest, apologies for the confusion around that.

1.0.0-rc-1 already flags unknown and deprecated rules when run, as will 1.0.0, so I believe we have our bases covered. There's just a weird moment in time right now between RC 1 and 1.0.0.

[Rob--W]

@nzakas As seen in one of my previous comments, rules with value 0 are not
shown. Did I overlook a flag / option to show them anyway?

(And this might be a temporary situation for now, but what will happen when
you release 2.0.0 in the future?)
On Jul 17, 2015 10:20 PM, "Nicholas C. Zakas" notifications@github.com
wrote:

@Rob--W https://github.com/Rob--W yeah, I messed up by making it work
with @latest, apologies for the confusion around that.

1.0.0-rc-1 already flags unknown and deprecated rules when run, as will
1.0.0, so I believe we have our bases covered. There's just a weird moment
in time right now between RC 1 and 1.0.0.

—
Reply to this email directly or view it on GitHub
#3039 (comment).

[ilyavolodin]

When we will release v2 RC, we will not mark it as latest.

[nzakas]

@Rob--W we don't check rules that are turned off because they can't affect execution.

[Rob--W]

@nzakas They don't affect execution, but they do take up space in the eslintrc files. Having an option to validate rule definitions would be nice.

That nice-to-have is not related to my initial issue, and my issue has several work-arounds, so I'll close this ticket. If you think that this suggestion is indeed a nice feature, feel free to open a new ticket for it.