Should not be an error: No files matching the pattern "entry.js" were found.

[fab1o]

Due to rule:

{
    rules: {
        'import/no-unused-modules': [
            'error',
            {
                ignoreExports: ['index.js', 'entry.js', 'main.js'],
                missingExports: true,
                unusedExports: true
            }
        ]
    }
}

I get the error:

> eslint . --ext .js


Oops! Something went wrong! :(

ESLint: 6.8.0.

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

If I dont have an "entry.js" file, it should just ignore it and move on.

However, I get the error even if I have an "entry.js" file :(

[ljharb]

Where does the config live exactly, and where does entry.js live exactly?

[fab1o]

the config lives in the root folder and entry.js lives in the source folder

[ljharb]

ok, so the path to entry.js from the config (and also from where you run the eslint command) is src/entry.js, not entry.js - what if you put that in your config?

[fab1o]

Yes, it works now. But I was hoping that it'd just ignore if it can't find the file. Because I want the config to be shared among different projects that not always will follow the same file name and path structure.

[ljharb]

In that case each project needs to define it themselves, which is all the more reason not to try to put that in the shared config. I don't think silently ignoring things is a good approach.

[astorije]

@ljharb, it's however pretty standard practice to have configurations silently ignore files that do not exist: .gitignore, .eslintignore, etc. And that's not just among *ignore files: include/exclude fields of tsconfig.json, files field of package.json, to name just a few.

In our projects, some have a webpack.config.ts we need this rule to ignore and some don't, some projects have a top-level index.ts and others have index.tsx where all things available outside the boundaries of each projects live (not the best example because index.ts{,x} is a valid pattern here).
Another example is our configuration has an entry for **/*.d.ts, which will break the linter when a project does not have any declaration files, but would work ok as long as there is a single file in the entire repo.

It does seem counter-intuitive to me, and the opposite of what most tools out there accustomed us to. Would you be open to reconsider your position on this? :)

[ljharb]

@astorije you're right about the common practice, for sure - altho that's probably caused more bugs than most, which is why eslint $x now errors out if you pass it an $x that results in no matched files - and i think eslint's example is a good one to follow for an eslint plugin. (this is even where the actual source of the error comes from, i believe)

I think it's reasonable in this case, however, that as long as at least one file is found in ignoreExports, an individual glob not matching should not error.

[astorije]

I agree with you that my-tool my-file.js should fail if my-file.js does not exist because you're explicitly passing an argument to a command, but that's a different use case IMO. Ignore lists do not usually cause a tool to fail if there is not at least one file from the ignore list that actually exists.

Until this behavior changes, we will not be able to use this rule organization-wide unfortunately, and I wouldn't be surprised if other teams that have shared configurations encountered the same issue.
I understand we can extend shared configurations per-repositories, but it makes it harder to ensure good practices organization-wide.

[ljharb]

I'd be happy to accept a PR that implemented the semantics I described. Would that address your use case? It seems like it would address the OP's as well.

[astorije]

I don't believe so. Given the following configuration:

ignoreExports:
  - webpack.config.ts

The shared configuration would fail on projects that have no webpack.config.ts files. Is that correct?

[ljharb]

Hmm, understood. I suppose it makes sense to avoid the error in cases like this.

[erikpukinskis]

The --no-error-on-unmatched-pattern flag was added in v6.8.0 of ESLint.

https://eslint.org/docs/user-guide/command-line-interface#no-error-on-unmatched-pattern

[ljharb]

Even better - if we can detect when that flag is passed, then we’d be able to follow it.