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

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 😦

[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.

[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? 😃