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

Don't require to specify deprecated rules #172

Closed
mgol opened this Issue Aug 31, 2016 · 14 comments

Comments

Projects
None yet
9 participants
@mgol
Copy link

mgol commented Aug 31, 2016

Currently the command eslint-find-rules -u ends with an error if you don't specify deprecated rules. Ideally that wouldn't be required; currently I just put them in a separate section and disable but that means my config will be broken as soon as those rules are removed which doesn't seem necessary.

I'm not sure if ESLint returns enough data to make it possible; if not we could make it happen upstream first.

@jfmengels

This comment has been minimized.

Copy link
Collaborator

jfmengels commented Aug 31, 2016

👍 I like the idea, and ESLint does return enough data to handle that (see this)

From what I can see, it could work for plugin rules too, if we're careful with the format of the rule (ESLint v2 and v3 format), and if they copy the same meta info behavior as ESLint.

The only downside to this, is that you'd need to require all core rules to find out whether they're deprecated, which would make the tool quite a lot slower I'm guessing, but it could be done only if needed, when the right flags are activated (if requiring all those rules is indeed that slow).

@ta2edchimp

This comment has been minimized.

Copy link
Collaborator

ta2edchimp commented Aug 31, 2016

👍 making the tool slower is worth it in this case, I guess! At least, when being behind a flag.

@mgol

This comment has been minimized.

Copy link

mgol commented Aug 31, 2016

I've reported an issue upstream that would help for this & similar use cases: eslint/eslint#7021 (and that would expose a proper API instead of having to hack into the internal ESLint package structure).

@mateatslc

This comment has been minimized.

Copy link

mateatslc commented Sep 12, 2016

look here for news on this: eslint/eslint#6525

@randycoulman

This comment has been minimized.

Copy link
Contributor

randycoulman commented Oct 7, 2016

I looked into doing this at one point and I really love the idea of having this feature.

From my earlier research, I only found one plugin that had deprecated rules (eslint-plugin-react), and it doesn't add a deprecated flag to the metadata. Instead, it exports a deprecatedRules property alongside its rules property.

It might be worth doing a couple of things:

  1. Submit a PR to eslint-plugin-react to add the deprecated property to its rule metadata.
  2. Update the ESLint plugin documentation to recommend doing that in all plugins.

Does anyone know of any other plugins that have deprecated rules? What do they do?

@ljharb

This comment has been minimized.

Copy link
Collaborator

ljharb commented Oct 8, 2016

I would be happy to accept that PR on eslint-plugin-react. eslint-plugin-import has some deprecated rules as well, iirc.

@randycoulman

This comment has been minimized.

Copy link
Contributor

randycoulman commented Oct 8, 2016

I'll try to work on a PR on eslint-plugin-react, but it might be a week or so before I can get to it. If anyone else wants to do it before then, feel free.

eslint-plugin-import just added its first deprecated rule in 2.0, but it's really just a rename of one rule to another, and it doesn't warn about the deprecated name when running it. I'll look at submitting a PR for that as well at my next opportunity.

@mvolkmann

This comment has been minimized.

Copy link

mvolkmann commented Oct 31, 2016

An example of a rule that is deprecated, but is flagged by eslint-find-rules as being unused is react/no-comment-textnodes.

@mgol

This comment has been minimized.

Copy link

mgol commented Dec 10, 2016

The ESLint PR has landed; I created an issue to switch to the new API: #211. Once that's done, this issue should be easily solvable.

randycoulman added a commit to CodingZeal/eslint-config-zeal that referenced this issue Feb 11, 2017

Don't fail if missing-rules:* scripts fail
`eslint-find-rules` currently reports deprecated rules as missing, and
so exits with a non-zero exit code.  This behavior makes the current
`missing-rules` npm script essentially useless.

For now, this adds the `—no-error` flag to all of the calls to
eslint-find-rules so that they always exit cleanly.

Once sarbbottam/eslint-find-rules#172 gets
done, we should be able to revert this change.  We could even then
include the `missing-rules` task in our CI validation suite, failing
the build if there are missing rules.

randycoulman added a commit to randycoulman/eslint-find-rules that referenced this issue Mar 11, 2017

refactor(find): Use new eslint getRules() api
Breaking change: Requires eslint >= 3.12.0

Starting with version 3.12.0, eslint provides a getRules()
API that allows us to directly access the rules rather than
trying to load them from the file system.  This is cleaner,
eliminates a dependency on the internal structure of the eslint
codebase, and may even be faster.

This change paves the way for further features involving
deprecated rules, such as sarbbottam#172 and sarbbottam#188.

Closes sarbbottam#211.

randycoulman added a commit to randycoulman/eslint-find-rules that referenced this issue May 2, 2017

refactor(find): Use new eslint getRules() api
Breaking change: Requires eslint >= 3.12.0

Starting with version 3.12.0, eslint provides a getRules()
API that allows us to directly access the rules rather than
trying to load them from the file system.  This is cleaner,
eliminates a dependency on the internal structure of the eslint
codebase, and may even be faster.

This change paves the way for further features involving
deprecated rules, such as sarbbottam#172 and sarbbottam#188.

Closes sarbbottam#211.
@alexilyaev

This comment has been minimized.

Copy link

alexilyaev commented May 4, 2017

@mgol @randycoulman Can we push this forward?
I see there's a PR that requires a review.

Or is there anything else missing?

@randycoulman

This comment has been minimized.

Copy link
Contributor

randycoulman commented May 4, 2017

We can't do anything here until #237 has been merged. Once that's done, we'll have to refactor a bit to use the new API to get the full rule definitions (we only use the rule names right now). Then we can filter out the deprecated rules.

@ntwb

This comment has been minimized.

Copy link

ntwb commented May 5, 2017

Looking forward to this 😄

ta2edchimp added a commit that referenced this issue May 5, 2017

refactor(find): Use new eslint getRules() api (#237)
Breaking change: Requires eslint >= 3.12.0

Starting with version 3.12.0, eslint provides a getRules()
API that allows us to directly access the rules rather than
trying to load them from the file system.  This is cleaner,
eliminates a dependency on the internal structure of the eslint
codebase, and may even be faster.

This change paves the way for further features involving
deprecated rules, such as #172 and #188.

Closes #211.
@randycoulman

This comment has been minimized.

Copy link
Contributor

randycoulman commented May 5, 2017

Now that #237 has been merged, this can be started. I plan to get to it as soon as I can, but I'm a bit busy right now and it might be a week before I get to it. If someone else wants to run with it, go for it - just let me know so I don't duplicate effort.

@ljharb

This comment has been minimized.

Copy link
Collaborator

ljharb commented May 5, 2017

It'd be good to cut a major release before merging this new option, imo.

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