Warning for ignored files on linting

[Salem]

Some context first: we use ESLint to evaluate changes to a large js codebase. When testing patches or deploying, we generate a list of changed files and run eslint on them explicitly, since running eslint across the whole codebase would be slow and unnecessary. Because of this, eslint is sometimes passed ignored files, which causes it to throw a warning (an error level we reserve for other types of errors), which causes false positives.

It seems like the answer to this problem has previously been to just run eslint on directories and to avoid lists of files or shell globs, but that doesn't quite work in this case. An option would be to just manually filter out errors like these based on text, but it seems strange that eslint outputs a warning that you can't disable, especially for something that's not an issue with code.

Note that this issue duplicates / expands upon #5623.

Tell us about your environment

• ESLint Version: 4.13.1
• Node Version: 8.9.3
• npm Version: 5.5.1

What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint

Please show your full configuration:

Configuration

{
    "env": {
        "amd": true,
        "browser": true,
        "jquery": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "prettier",
        "prettier/react"
    ],
    "globals": {
        "_": false,
        "Backbone": false,
        "Etsy": true,
        "has": false,
        "Raven": false
    },
    "parser": "babel-eslint",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        }
    },
    "plugins": [
        "react",
        "prettier"
    ],
    "rules": {
        "eqeqeq": ["error", "always"],
        "no-unused-vars": ["error", {
            "vars": "all",
            "args": "none",
            "ignoreRestSiblings": false
        }],
        "no-use-before-define": ["error", {
            "functions": false,
            "classes": true,
            "variables": true
        }],
        "react/jsx-uses-react": ["error"],
        "react/jsx-uses-vars": ["error"],
        "react/prop-types": ["warn"],
        "react/react-in-jsx-scope": ["error"],
        "prettier/prettier": ["warn", {}]
    },
    "root": true,
    "settings": {
        "react": {
            "version": "15.4.2",
            "createClass": "createClass"
        }
    }
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

# modified_js_files.txt is generated from a git patch programmatically,
# and contains either ignored files or lint-free files.
 cat modified_js_files.txt | xargs eslint --format checkstyle > $WORKSPACE/eslint-results.xml

What did you expect to happen?
I expected there to be no warnings

What actually happened? Please include the actual, raw output from ESLint.
There is a single warning:

/path/to/an/ignored/file.js
  0:0  warning  File ignored because of a matching ignore pattern. Use "--no-ignore" to override

✖ 1 problem (0 errors, 1 warning)

[Salem]

As a follow-up, it actually looks like this option used to exist, but was removed potentially by mistake: #4931

[Salem]

Any word on this?

[Xandor Schiefer]

I also am having an issue because of this.

I use the different severities (error and warning) for different purposes:
error stops builds and commits, it is only used for rules that cover guaranteed runtime or logic errors,
warning stops commits (unless overridden, e.g. using git's --no-verify flag), but not builds (so warnings can be ignored for dev builds with hot module reloading, hotfixes, or other reasons).

The precommit tool I'm using (https://github.com/okonet/lint-staged) only fails the check on a non-zero exit code. So, I need to set ESLint's --max-warnings=0 to have ESLint treat warnings as errors for exit code purposes.

Unfortunately it feeds the file directly to ESLint, which raises the warning:

File ignored because of a matching ignore pattern. Use "--no-ignore" to override

for ignored files, and exits with 1 because of --max-warnings=0, causing the pre-commit hook to fail even though everything is correct.

The problem isn't really that this warning is raised, it's that it's unconfigurable. During my google searches about this problem it seems that over the years several other tools in the ecosystem have run into problems with this warning, notably editor linting integrations. The response from ESLint has been to call ESLint on a directory instead of a file directly, but sometimes this is not possible.

Some of the affected projects have been able to work around this issue by specifically ignoring the warning by matching the warning text against a regex, but this is brittle (warning text isn't exactly considered a public API and if it were ever changed it could break other tools' suppression of this warning), and in some cases not possible (e.g. in my case where I'm only able to rely on the exit code).

The fact that this keeps coming up for different reasons and projects speaks to a need to be able to configure this using a public, stable API.

Personally, I think having it as a built-in rule or setting is best, but I'd be happy with a CLI flag, too.

[Salem]

Any updates on this PR? I know the maintainers are probably swamped with more important stuff, but any sort of guidance would be appreciated.

[Teddy Katz]

Hi, sorry about the lack of a response here -- it looks like this issue slipped through the cracks. I think having a CLI option makes sense here -- it seems like we already expose this behavior through CLIEngine.executeOnText as an undocumented third argument, but the option isn't exposed as a CLI flag. I'll add this to the TSC agenda, so hopefully we will have a decision soon.

[Teddy Katz]

TSC Summary: This issue proposes adding a command-line flag to disable "this file is ignored" warnings for ignored files, and instead simply report no errors when a path to an ignored file is provided. This would be useful for integrations (many integrations currently get around this problem by manually filtering out reports that match the "this file is ignored" message).

TSC Question: Should we accept this proposal?

[Salem]

@not-an-aardvark thank you! Much appreciated.

[Brandon Mills]

@salemhilal During today's TSC meeting, @not-an-aardvark helpfully pointed out the isPathIgnored API, so I wrote up a quick script that you could add that I think might solve your problem without any new features!

// filter-ignored.js
var split = require("split");
var CLIEngine = require("eslint").CLIEngine;
var cli = new CLIEngine({});

process.stdin.setEncoding('utf8');
process.stdin.pipe(split()).on('data', function (file) {
    if (!cli.isPathIgnored(file)) console.log(file);
});

Usage:

$ ls src/*.js
src/bar.js     src/foo.js     src/ignored.js src/xyz.js

$ cat .eslintignore
src/ignored.js

$ ls src/*.js | xargs node_modules/.bin/eslint

~/code/eslint/test/src/ignored.js
  0:0  warning  File ignored because of a matching ignore pattern. Use "--no-ignore" to override

✖ 1 problem (0 errors, 1 warning)

$ ls src/*.js | node filter-ignored.js
src/bar.js
src/foo.js
src/xyz.js

$ ls src/*.js | node filter-ignored.js | xargs node_modules/.bin/eslint

[Teddy Katz]

By the way, I think I mentioned during the TSC meeting that the warnIgnored option in CLIEngine is undocumented, but I realized just now that I was incorrect and it actually is documented here:

If a filename in the optional second parameter matches a file that is configured to be ignored, then this function returns no errors or warnings. To return a warning instead, call the method with true as the optional third parameter.

I'm not sure if this affects peoples' opinions on adding a CLI flag, but I thought I'd bring it up as a correction in case my claim that the option was undocumented was an important aspect of peoples' view on the issue.

---

Regarding using a Node script to filter out ignored files, my initial impression is that if the user is writing a node script anyway, they might as well just use the API for the whole process (by calling CLIEngine.executeOnFiles in the node script). I'm of the opinion that we should expose the functionality directly on the CLI somehow, whether that's through exposing the isPathIgnored API or the warnIgnored flag.

[Teddy Katz]

In today's TSC meeting, the TSC decided not to accept this feature. We recommend using CLIEngine if you'd like to query ESLint about ignored files or suppress the warning about them.

[Xandor Schiefer]

I feel like the notes from the discussion didn't at all address command line useage scenarios. Sure, we can write scripts to use the options, but the command line is the preferred way in *NIX land to tie together different scripts and tools.

This just creates extra work for the ecosystem that relies on ESLint.

[Teddy Katz]

You might also be interested in reading the meeting archive, which has the full discussion and a bit more detail on CLI usage scenarios.

[Salem]

@not-an-aardvark thank you for exploring this in the TSC meeting. That chat log was definitely insightful. I'll stick with the script we wrote to ignore that particular error for now.

Not sure if it means much, but warnings seem to typically indicate code-related issues rather than runtime-related issues. It seems to have been addressed in passing, but is there a strong case for keeping this warning at all, as opposed to removing it in the next major version bump? To reiterate, this isn't a serious problem for us either way; that script is doing its job just fine.