eslint: Add an option to not throw an error on an unmatched pattern

I think there are relatively few use cases for this option (one of which might be running eslint in an integration), but I don’t object to adding it. That said, if you’re encountering an error like this when running ESLint from the command line, the solution should usually be to stop trying to lint non-existing files, not to add a flag to make ESLint ignore your errors. This issue has a lot of 👍s in comparison with the narrowness of the use case, which makes me suspect that some people are misunderstanding what the error message is saying.

I think this issue was closed prematurely. Many people (including me) want to be able to save time and share ESLint scripts across different projects (with sometimes non-existing paths in the glob).

It could be easily solved by adding a new CLI flag to skip glob entries that result in no paths.

If somebody from admin team are still reading this, please consider reopening this issue.

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

Per discussion in the 2019/04/11 TSC meeting, this is now accepted. (Apologies for not following up here.)

This definitely should be re-opened and fixed. Just faced with this strange behaviour on version v5.15.0. tested with Node 6 & 8.

Eslint should NOT fail if it can’t find some files from a pattern.

I’ll reopen this. We need to at least evaluate this as a TSC for sure.

I’m gonna take a look at this over the weekend and see if it’s something I can tackle

Hi @brunoscopelliti, have you tried quoting the globs like eslint "app/**" --ext .js? It’s possible that your shell is expanding the globs to a list of files before passing the files to ESLint, and the expanded list of files includes some folders that don’t contain any lintable files.

I’d like to second that. We’re working on legacy code which is close to impossible to refactor to our eslint rules, so we use git log to generate a list of changed files that eslint should run on. But sometimes this will included deleted files, breaking our workflow. Adding an option to just keep going would be extremely helpful.

@not-an-aardvark correct. And I did it before v5.

Tooling should exit silently if it doesn’t apply to any files.

This proposal has been accepted. PRs welcome!

I don’t know what my schedule will be this afternoon, so in case I don’t make it to the TSC meeting, I left a 👍 on the TSC summary above. It seems like the new default behavior works for most users, but the use cases described here justify an opt-out.

If you’ll allow me to bike-shed a bit, I have a slight preference for option names like unmatched glob or unmatched pattern, since “missing files” sounds ambiguous to me. Having a long option name shouldn’t be an issue since the use case here is a write-once shared script, and users wouldn’t be typing it on every invocation.

TSC Summary:

In ESLint 5.0.0, we started throwing errors when nonexistent directories or files, or glob patterns that don’t match any files, were passed to ESLint. The assumption was that users would want to know when a file wasn’t being linted as it could be due to a misspelling. However, this has caused unforeseen side-effects for some tooling, where the intention is to create lint scripts that will lint certain files as they are created in a new project.

Numerous members of the community are asking that we add a CLI option to enable the old behavior on an opt-in basis. Example option names: --no-error-on-missing-files, --no-error-on-unmatched-pattern

TSC Question:

Should we invite contributions for a new CLI option to suppress errors when lint target files/directories are not found, or globs match no patterns?

This seems reasonable to me as long as the default behavior remains unchanged. Let’s see what others say.

Edit: typo

Anyone has some workaround for this issue. I’m migrating from js to typescript and eslint not support as operator then I disable to lint ts files but doing this brake the linting of the rest of js files. 😦

@ozaytsev86 In your case, you might be able to use --diff-filter=d to remove the deleted paths from consideration and avoid the problem.

I just tried to upgrade to eslint@5 and i ran into the same issue.

I have a “starter-kit” project with all the backbone code that I then fork to create other projects.

I have an eslint command that is trigged by the ci to lint my sources files, as well as my test files. The starter-kit project doesn’t have any test files since it has nothing to test, but i don’t think the linting script should fail because of it…

Here are the scripts

{
  "eslint:source": "eslint . --ignore-pattern=*.spec.js --ext=.jsx --ext=.js",
  "eslint:test": "eslint . -c=.eslintrc.test --ext=.spec.jsx --ext=.spec.js",
  "eslint": "npm run eslint:source && npm run eslint:test"
}

And the Error

No files matching the pattern "." were found.

Thanks for fixing this, or at least provide an option to not fail on empty test suites. Otherwise I have to add a dummy empty test file in the starter-kit project, which is lame.

I would like this too as some of my projects dont have certain files. I make lots of projects a day so its hard to constantly adjust the command.