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

The version of ESLint you are using.

ESLint: 5.1.0.

The problem you want to solve.

Since breaking behaviour change 8b7c6eaed39e8506dba1aa6e57b1d0e2fdc351c3 #7390 #10143 bundled in ESLint 5, a fatal error is thrown if any file pattern return no files.

My company is using a generic ESLint configuration/runner for all our projects, and we are pretty happy with that:

eslint \
  --ext .js --ext .jsx --ext .mjs \
  -- src test "packages/*/src" "package/*/test"

The problem is that not ALL of our projects matches the same patterns, and we got this error since we upgraded to eslint@5

No files matching the pattern "test" were found.
Please check for typing mistakes in the pattern.

We don’t want to implement custom code to check for pattern existence before appending them to eslint CLI parameters (and we where really happy with eslint@4 behaviour on this particular case).

NOTE: This issue is a bit related to https://github.com/eslint/eslint/issues/9977

Your take on the correct solution to problem.

Add a CLI option (exactly like how proposed here) not to throw errors on unmatched patterns.

Something like --no-error-on-missing-files or --no-error-on-unmatched-pattern

[not-an-aardvark]

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.

[revelt]

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.