Add the --quiet option (to only output errors and not warnings) to the configuration file

[un33k]

Please describe what eslint should do:

This is not a rule request, but a config option request.

You have implemented the --quiet option via command line which is great. However, many frameworks now-a-days implement their own CLI and, many can handle eslint, via .eslintrc or .eslintrc.json, but not all can handle the --quiet option.

For example, Nrwl has NX and after many requests they've added the --quiet option pass through, which doesn't work. Somewhere between the Nx CLI and Angular CLI and eslint the --quiet option is dropped or ignored.

Please note, that using eslint directly is not an option, as Nx CLI has an option to only lint the affected libraries (that have changed), and we have 100s of them in our large application. So, affected:lint is a time saver in our CI, and we must use their CLI.

We have upgraded to NG 10 and our lint log is unusable due to thousands of warnings, that we have to ignore at this moment. But finding the errors becomes really hard in such scenario.

This request is to also add the --quiet option to each section of the config file, so we can set it & forget it, without falling to the mercy of in-between CLIs.

What category of rule is this? (place an "X" next to just one item)

[ ] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ x ] Other (please specify:)

Pls make command line options also available via configuration files. With overwrite possibility. (during extends)

Provide examples :

357:89 warning Unexpected any. Specify a different type @typescript-eslint/no-explicit-any

The above warning and 1000s like it, are just fine at this stage of our application upgrade process.
Be great if we can hide them for now via a configurable quiet option, to be address at a later time, this way, we can see the real errors.

[mdjermanovic]

Hi @un33k, thanks for the proposal!

I'm not sure if this option makes sense at the config level. Setting quiet: true in a config would basically disable all rules set to warn, which can be already achieved by simply not enabling those rules in the same config, or setting them to off if they were enabled in a shared config.

[un33k]

Hi @mdjermanovic, with 20+ warning rules in the main config file and more in derived config files, going through and "off"ing them all, is more work than flipping a central switch. Later on, we have to fall on git history to see if we went to "off" from "error" or "warning", etc. This request is simply to have a configurable option that is the parity of --quiet in functionality, so we can bypass the third-party CLIs easily, at one place.

Most importantly, I still want the warnings in the IDE, just not in my log files on the CI system. "off" turns them both "off".

[mdjermanovic]

Most importantly, I still want the warnings in the IDE, just not in my log files on the CI system.

Thanks for clarifying, this is certainly a valid use case and supported by the --quiet CLI option. However, that seems like an unexpected behavior for a config option. All settings in configuration files are supposed to apply regardless of the way ESLint is used (CLI or API).

Currently, there are no CLI-specific options in ESLint config files. I think this option doesn't seem like a good fit for configuration files, but would like to hear opinions from the rest of the team.

If there is an issue with passing through --quiet, a workaround could be to conditionally disable rules, e.g.:

const offCI = ["some-rule", "another-rule" //, ...];

module.exports = {  
  "rules": {
    // ...
    ...isCI ? Object.fromEntries(offCI.map(r => [r, "off"])) : {}
  }
};

[nzakas]

Yeah, this doesn’t seem like a good fit in configuration files. The use case is fairly narrow and I don’t think warrants mixing CLI options with config options.

[un33k]

Just note that with all those frameworks and their CLIs out there, very few projects use eslint CLI directly. And those in-between CLI's limiting factors passes on to eslint directly. So, Eslint's greatness will always be bound to other's schedule, desire for quality & etc.

Like everything else out there, Eslint is best to provide a configurable LogLevel = ERROR | WARN | INFO | DEBUG, that is overwritable by all sub-configs and ultimately via the command line options. (If we wanted to do it right).

Thx

[Antonius-S]

For example, Nrwl has NX and after many requests they've added the --quiet option pass through, which doesn't work. Somewhere between the Nx CLI and Angular CLI and eslint the --quiet option is dropped or ignored.

Isn't that an issue in Nx? There's many command-line arguments in ESLint so the caller must provide means to define them and correctly transfer them to launched process.

[eslint-deprecated]

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.