sarbbottam / eslint-find-rules Goto Github PK

When it runs in a project containing only ".ts" files (so not any ".js" file) this error occurs:

It seems that the issue come from this line :

It could be nice to have a way to configure the glob pattern or maybe just the extension part (see --ext option in eslint cli https://eslint.org/docs/user-guide/command-line-interface#options)

Thanks!

When adding TypeScript support in eslint-config-kentcdodds (see kentcdodds/eslint-config-kentcdodds#54), I noticed CI isn’t failing even though I haven't added all @typescript-eslint rules (yet).

I'm happy to help out if you could point me into the right direction of adding support here. 🙂

I noticed that this newly added rule was added in @typescript-eslint/eslint-plugin, and I realized that it was not being found by this tool. 😦

Perhaps this is an issue with scanning monorepos?

Just upgraded to v3, seeing duplicate results when running:
eslint-find-rules -u .eslintrc -n

babel/new-cap               babel/new-cap               babel/no-invalid-this
babel/no-invalid-this       babel/object-curly-spacing  babel/object-curly-spacing
babel/semi                  babel/semi

You can check it out here:
https://github.com/alexilyaev/react-es6-starter

When using @typescript-eslint/eslint-plugin I'm getting the error:

Error: Cannot find module 'eslint-plugin-@typescript-eslint'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:580:15)
    at Function.Module._load (internal/modules/cjs/loader.js:506:25)
    at Module.require (internal/modules/cjs/loader.js:636:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at /Users/chris/github/eslint-config/node_modules/eslint-find-rules/dist/lib/rule-finder.js:68:26
    at Array.forEach (<anonymous>)
    at _getPluginRules (/Users/chris/github/eslint-config/node_modules/eslint-find-rules/dist/lib/rule-finder.js:66:13)
    at new RuleFinder (/Users/chris/github/eslint-config/node_modules/eslint-find-rules/dist/lib/rule-finder.js:104:21)
    at module.exports (/Users/chris/github/eslint-config/node_modules/eslint-find-rules/dist/lib/rule-finder.js:151:10)
    at Object.<anonymous> (/Users/chris/github/eslint-config/node_modules/eslint-find-rules/dist/bin/find.js:33:18)

Atom's linter-eslint project holds a list of plugin and plugin rules documentation location pair (see https://github.com/AtomLinter/linter-eslint/blob/master/lib/helpers.js#L72-L104). Basically: "For eslint plugin X, the documentation for every rule is in https://github.com/Gillespie59/eslint-plugin-X/blob/master/docs/' + ruleName + '.md'.

What do use it for, is at the location where errors are shown, to have a clickable link that opens the browser with the documentation page of that link, which allows you to easily read more about the rule and/or the problem it points out. (in the following screenshot, no-undef is clickable)

A while ago, I thought about moving this project to its own repo (that I discussed in one of the points here), and the creators thought it could be a good idea.

I now thought that this could be pretty useful here. Behind an option, there could be new list formatted like this:

accessor-pairs http://eslint.org/docs/rules/accessor-pairs
array-bracket-spacing http://eslint.org/docs/rules/array-bracket-spacing
array-callback-return http://eslint.org/docs/rules/array-callback-return

import/order https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md

which would be clickable in the terminal (hopefully in most terminals, otherwise it's copy-pastable, which is still nice), and allow you to quickly find out about a rule.

Right now, I'm wondering whether you'd be interested by this functionality. And if so, I'll be more interested in working on the new repository the plugins (and maybe even integrate it here) :)
What do you think?

FYI: Currently, as that "list" works, every link for an unknown plugin will redirect to a page to help register it.

I'd love to know what changes between versions without having to read the commit log :-)

test bin.js

Hi all!

I'm updating a eslint config package we use at my company (https://github.com/CoorpAcademy/eslint-plugin-coorpacademy, if you need to know. It's a eslint-plugin rather thant eslint-config because it allows us to bring external dependencies with it), and I'm using this tool to find what rules are new and missing in my config files.

We have a core config, which configures all core ESLint rules, and I can use eslint-find-rules --unused ./config/core.js to get the list of missing rules, works great here 👍, it even includes the missing rules in the plugins I declared in the file.

We also have multiple configs for certain cases, to activate on each project depending on the needs, mostly focused on the libraries we use, for instance mocha and AVA. For those plugins, I'd like to get the list of missing rules, but only for the plugins that I declared in that configuration, and not the core rules, as I have defined them in another file anyway.

When doing eslint-find-rules --plugin ./config/ava.js, it prints all rules, but not the unused ones.
When doing eslint-find-rules --unused ./config/ava.js, it prints all missing rules, but also the core ESLint rules.
When doing eslint-find-rules --unused --plugin ./config/ava.js, it prints all rules, and the plugin rules twice.

Having the core rules listed causes two problems for me:

• It's hard to find whether or not I actually have missing rules in the big blob of text
• The command exits with an error code, meaning I can't chain commands like eslint-find-rules --unused ./config/ava.js && eslint-find-rules --unused ./config/mocha.js && ...

In short, what I'd like to have is a mean to not list core rules. Maybe something like --no-core?

Thanks a lot for the tool by the way :)

Tracking issue for adding eslint v6 to travis-ci and peer deps.

(ref airbnb/javascript#2036)

semantic release is broken for past few releases.

https://travis-ci.org/sarbbottam/eslint-find-rules/jobs/171707833#L355

 The commit the last release of this package was derived from is not in the direct history of the "master" branch.

@sarbbottam: Please don't approve it via GitHub means, otherwise, the PR will get merged

@ljharb: @sarbbottam i'd strongly caution against automerging on PR approval; i don't even think semantic-release is a safe idea.

@sarbbottam:@ljharb I guess I was wrong about auto-merging. It is not enabled. I had to merge #199 by myself.

I'd strongly caution against auto-merging on PR approval;

Agreed

semantic-release

Yea, it could be problematic sometimes, but has its benefits too. I am a bit biased but would be OK to let it go, if we all think so.

@ta2edchimp: So, is it safe to approve the requested changes? (I never worked with the review feature before ...)

Re: auto merge on review approval

Can we assure this is not activated?

Re: semantic release

Besides "spamming" with updates when lots of PRs would get merged within a short period of time, I see no problem in having automatic releases for this tool. But this is something we should discuss / evaluate in a separate issue.

is-global.js fails in node 4.4

• https://travis-ci.org/ljharb/eslint-config/jobs/128434647#L499
• https://travis-ci.org/ljharb/eslint-config/jobs/128433311#L491

Utilization is commented now, refer #83
Does it even make sense to keep it or just update the README, that this must not be used as a global utility.

@ta2edchimp @kentcdodds thoughts.

I'd like to run a command that ensures that for all rules I have defined, I've defined every possible compatible schema option.

For example, for the "indent" rule, http://eslint.org/docs/rules/indent points out that it can have an object option with 12 different options. I'd like a report, for that rule, of any of the 12 I've omitted in my config.

I would be better to release this package asap, if we consider its current state is good enough for MVP

Then we have to put a deprecation notice to eslint-find-new-rules and point it to this one.

Other wise we may end up addressing the same issues, in both the repo.

In package.json we have:

"scripts": {
    "check-kentcdodds": "./bin.js eslint-config-kentcdodds"
  }

but running it will fail, due to

• ./bin.js not existing,
• eslint-config-kentcdodds not being successfully resolved.

@sarbbottam do we need this npm script?

Current output looks a bit clumsy, can we make it better?

Would it be better to setup gitter for discussion?
/@ta2edchimp

Instead of hard code eslint directory, use require.resolve to detect it.

If no eslint is found in the PATH display proper error.

Refer #69

Since the src/ is in es5, let the tests be in es5 too.

Thanks for great tool 👍

Did we discuss this? It's no big deal, but it was just a bit surprising and probably unnecessary....

This works for me as an npm script:

    "efr": "eslint-find-rules --unused ~/.eslintrc -n"

This does not work. It outputs errors despite the --no-error flag.

    "efr": "eslint-find-rules --unused ~/.eslintrc --noerror"

I don't understand why it outputs errors anyway though.

Add a --verbose option. When used, print for example when there's no rule unconfigured (atm. this has no output at all).

We could easily make use npm-log for this.

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.

README.md

• badges
• description
• acknowledgement to the original module
• add gitter room link

Repo

• change the repo's description
  • will be updated once #11 is merged

Should the codebase be ES2015fied?

@ta2edchimp @ljharb @jfmengels

Add an option to compare the rules configured by two (or even more?) ESLint configs.

... what do you think about the idea of colorising the verbose diff output? In case it's a lot, printed on screen, I think it would definitely help getting the major differences at first glance ...
~ @ta2edchimp

Take the following minimal .eslintrc.yaml:

extends: eslint:recommended

When I run eslint-find-rules -c .eslintrc.yaml it dumps a list of every eslint rule, which is extremely unhelpful.

I think the problem here is that eslint:recommended is implemented by setting the value for non-recommended rules to off instead of leaving them out. The only workaround I can think of for this is to explicitly mask out eslint:recommended and then later fill them back in. However, this seems like a bit of a bodge; is there a better way to do this?

The alternative is to add a flag such as --off-is-unused to consider any rules which have been turned off to be unused. Of course, that would prevent rules from being removed from the list.

For example, the ESLint getter-return rule shipped in ESLint 4.2

This rule is not included in the ESLint recommended config but is listed in the Possible Errors category: https://github.com/eslint/eslint/blob/master/lib/rules/getter-return.js#L49

Currently if I run eslint-find-rules --unused --no-error on my shared config this returns ~40 rules that I don't use and have no plans on using.

It'd be great if I could do eslint-find-rules --unused --no-error --category possible-errors, that would make it super easy to run after updating ESLint to determine if any new Possible Errors rules have shipped in ESLint.

I updated eslint to v3.1.0 in https://github.com/ljharb/eslint-config and ran npm run prepublish (which runs eslint-find-rules --unused, among other things).

It complains about two missing rules: "multiline-ternary" which is a new one added in v3.1.0, and ".eslintrc.yml", which is not a rule at all.

If no options are provided, warn the user.

Refer #69

Using this:

eslint-find-rules -u -p .eslintrc --no-core

Results in this:

plugin rules

jest/consistent-test-it            jest/lowercase-name                jest/no-disabled-tests             jest/no-focused-tests
jest/no-hooks                      jest/no-identical-title            jest/no-jest-import                jest/no-large-snapshots
jest/no-test-prefixes              jest/prefer-expect-assertions      jest/prefer-to-be-null             jest/prefer-to-be-undefined
jest/prefer-to-have-length         jest/valid-describe                jest/valid-expect                  jest/valid-expect-in-promise
lodash/callback-binding            lodash/chain-style                 lodash/chaining                    lodash/collection-method-value
lodash/collection-return           lodash/consistent-compose          lodash/identity-shorthand          lodash/import-scope
lodash/matches-prop-shorthand      lodash/matches-shorthand           lodash/no-commit                   lodash/no-double-unwrap
lodash/no-extra-args               lodash/no-unbound-this             lodash/path-style                  lodash/prefer-compact
lodash/prefer-constant             lodash/prefer-filter               lodash/prefer-flat-map             lodash/prefer-get
lodash/prefer-includes             lodash/prefer-invoke-map           lodash/prefer-is-nil               lodash/prefer-lodash-chain
lodash/prefer-lodash-method        lodash/prefer-lodash-typecheck     lodash/prefer-map                  lodash/prefer-matches
lodash/prefer-noop                 lodash/prefer-over-quantifier      lodash/prefer-reject               lodash/prefer-some
lodash/prefer-startswith           lodash/prefer-thru                 lodash/prefer-times                lodash/prefer-wrapper-method
lodash/preferred-alias             lodash/prop-shorthand              lodash/unwrap                      promise/always-return
promise/avoid-new                  promise/catch-or-return            promise/no-callback-in-promise     promise/no-native
promise/no-nesting                 promise/no-new-statics             promise/no-promise-in-callback     promise/no-return-in-finally
promise/no-return-wrap             promise/param-names                promise/prefer-await-to-callbacks  promise/prefer-await-to-then
promise/valid-params

plugin rules

jest/consistent-test-it            jest/lowercase-name                jest/no-disabled-tests             jest/no-focused-tests
jest/no-hooks                      jest/no-identical-title            jest/no-jest-import                jest/no-large-snapshots
jest/no-test-prefixes              jest/prefer-expect-assertions      jest/prefer-to-be-null             jest/prefer-to-be-undefined
jest/prefer-to-have-length         jest/valid-describe                jest/valid-expect                  jest/valid-expect-in-promise
lodash/callback-binding            lodash/chain-style                 lodash/chaining                    lodash/collection-method-value
lodash/collection-return           lodash/consistent-compose          lodash/identity-shorthand          lodash/import-scope
lodash/matches-prop-shorthand      lodash/matches-shorthand           lodash/no-commit                   lodash/no-double-unwrap
lodash/no-extra-args               lodash/no-unbound-this             lodash/path-style                  lodash/prefer-compact
lodash/prefer-constant             lodash/prefer-filter               lodash/prefer-flat-map             lodash/prefer-get
lodash/prefer-includes             lodash/prefer-invoke-map           lodash/prefer-is-nil               lodash/prefer-lodash-chain
lodash/prefer-lodash-method        lodash/prefer-lodash-typecheck     lodash/prefer-map                  lodash/prefer-matches
lodash/prefer-noop                 lodash/prefer-over-quantifier      lodash/prefer-reject               lodash/prefer-some
lodash/prefer-startswith           lodash/prefer-thru                 lodash/prefer-times                lodash/prefer-wrapper-method
lodash/preferred-alias             lodash/prop-shorthand              lodash/unwrap                      promise/always-return
promise/avoid-new                  promise/catch-or-return            promise/no-callback-in-promise     promise/no-native
promise/no-nesting                 promise/no-new-statics             promise/no-promise-in-callback     promise/no-return-in-finally
promise/no-return-wrap             promise/param-names                promise/prefer-await-to-callbacks  promise/prefer-await-to-then
promise/valid-params

unused rules

jest/lowercase-name                jest/no-hooks                      jest/no-jest-import                jest/no-test-prefixes
promise/no-new-statics             promise/prefer-await-to-callbacks  promise/prefer-await-to-then       promise/valid-params

Reproduce

• https://github.com/alexilyaev/stylelint-find-rules/tree/eslint-find-rules-plugin-only
• Run npm run eslint-find-rules

WS-2018-0236 More information
moderate severity
Vulnerable versions: < 4.0.0
Patched version: 4.0.0
In nodejs-mem before version 4.0.0 there is a memory leak due to old results not being removed from the cache despite reaching maxAge. Exploitation of this can lead to exhaustion of memory and subsequent denial of service.

npm ls mem shows:

└─┬ [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └── [email protected] 

We now output urls in verbose mode, but it's not necessarily always very clear that they are urls (it's a big blob of text at first glance, especially when the terminal is not very big)

I just discovered Zeit's now, which outputs urls this way:

(it's even clearer when I hover the url in my terminal, but don't know how to make a screenshot of that on my computer)

and I found that this is the way it does that, using chalk.

I don't know what you think, but this looks to me like a nice addition to the tool :)

We need a semver-minor to add eslint v7 to the peer deps.

So, first, 93a68b6 is a breaking change, and should not have been released as a minor version.

Second, it is failing for me when run as a local utility. Using npm run-scripts, eslint-find-rules can be invoked directly, since npm puts it in the PATH - so your method of determining "is global" is flawed.

Please add option to print as a list - each rule in one line.

Currently exit status is 0, the original module used process.exit(1), I removed that on purpose, I did not want the error to scroll past the viewport.

Should there be an option --exit=1 default to 0?
May be in CI environment exit status is 1?

Thoughts?

• update repo name
• update repo description
• set up gitter room

In addition to #172, which would keep eslint-find-rules from reporting errors when deprecated rules are unused, it might also be nice to have a command-line option that shows deprecated rules that are still being used in a configuration.

eslint has dropped support for node < 4, Should eslint-find-rules do the same?

If not, we have restrict the dependent eslint version < 3 to get the build pass

@ta2edchimp @ljharb thoughts?

Now we have stable v4 https://github.com/eslint/eslint/blob/master/CHANGELOG.md

My project has a non-shareable config. I was hoping for a workflow where I install this globally and do

$ eslint-find-rules .eslintrc.json

and it shows me which rules I haven't configured. However, this failed in two ways:

• First, it wouldn't work until I also globally installed eslint. That's sad.
• Second, even after I did that, it always output nothing. I tried deleting random rules from my config, and nothing happened.

Now that eslint/eslint#7669 has landed this tool can switch to the new getRules() API and stop reading the ESLint package contents (unless the API is not available, i.e. for older ESLint versions).

This will make the tools independent of ESLint potentially changing its package structure which is private and would make it possible to add features like #172.

While I think the author on a package's page in npmjs.org is determined by the user doing the initial publication, I wonder if we should update at least the contributors field in package.json.

Should the package name be eslint-find-rules? Similar to its predecessor eslint-find-new-rules?

Not sure, but I guess
eslint-find-rules [option] <filename>
it sounds better than
eslint-rule-finder [option] <filename>

a verb seems better than a noun, in this case.

Thoughts?