CLI option --color is missing in documentation

[ralfstx]

The command line option --color is actually useful to enforce ANSI color codes when outputting to a pipe, e.g. in a Grunt task.

Apparently, this options is supported in ESLint 2.8.0, but it's missing in the online doc and also in the output of

eslint -h

[alberto]

It's present as --no-color, since it's true by default.

[alberto]

Since it doesn't really seem like an issue, I'm closing this. Please reopen if there is something I am missing here

[ralfstx]

Actually, the colors are missing when writing to a pipe. So the --colors options is useful when calling eslint using exec, e.g. from a build task. I only found it by accident.

I don't quite understand why you do not care to document parameters that are available.

I would re-open but it seems I can't.

[platinumazure]

Can you please provide exact repro steps showing where the absence of --color results in no colors (contrary to what we believe is the default), but where the presence of --color results in colors? This question started as an assumption that something was not documented, but in reality there may be a behavioral quirk (or even a bug) at play. If there is a bug, we need to know how to recreate it.

Incidentally, the tone in this sentence:

I don't quite understand why you do not care to document parameters that are available.

Is non-constructive and makes assumptions about our values and practices that simply aren't true. Please let's try to figure this out in a constructive manner. Thanks!

[nzakas]

The --color flag is just passed through to Node, we don't actually do anything with it. We can only output either --no-color or --color using the CLI utility, but not both.

[eslintbot]

Hi @ralfstx, thanks for the issue. It looks like there's not enough information for us to know how to help you. If you're reporting a bug, please be sure to include:

1. The version of ESLint you are using (run eslint -v)
2. What you did (the source code and ESLint configuration)
3. The actual ESLint output complete with numbers
4. What you expected to happen instead

Requesting a new rule? Please see Proposing a New Rule for instructions.

If it's something else, please just provide as much additional information as possible. Thanks!

[ralfstx]

@platinumazure

the tone in this sentence ...

Sorry for that, I didn't mean to offend anyone. However, it's frustrating when you take the time to report a minor issue and see it being closed without the issue being addressed.

Can you please provide exact repro steps showing where the absence of --color results in no colors ...

Given a file with linting errors, the following command's output contains colors:

eslint fileWithErrors.js

while the following command does not:

eslint fileWithErrors.js | cat

It's all expected behavior, I'm just asking to add --colors to the documentation. If you point me to the source file, I'm happy to provide a pull request.

[meeber]

Hi :D

I agree that it would be useful for the --color option to be documented even though color is usually displayed by default. It's helpful to know that --color can be used to force color to be displayed in situations in which it wouldn't be displayed by default.

@ralfstx mentioned piping it through cat as an example. Another example is when invoking eslint via exec in a ShellJS script. In both situations, color isn't displayed unless --color is provided.

An example of a project that documents both --colors and --no-colors despite color being displayed by default is Mocha: https://mochajs.org/#usage

Appropriate verbiage could then be:

Output:
  -o, --output-file path::String  Specify file to write report to
  -f, --format String        Use a specific output format - default: stylish
  --color                    Force enabling of colors
  --no-color                 Force disabling of colors

Thanks!

[nzakas]

@ralfstx @meeber as I mentioned above, our tool for handling CLI output, optionator, does not support outputting both options. We use this both on the command line and to generate the documentation, so this isnt a matter of just updated the docs.

If anyone has a suggestion for how to overcome that limitation, we are open to suggestions.

Also, keep in mind that we have almost 200 open issues. We can't fix every issue that is filed, so we need to prioritize and close issues that we don't intend to address. That may be frustrating, and that's unfortunate. I just ask you to keep in mind that the ESLint team is entirely a volunteer team working in their free time on ESLint, and we are doing the best we can.

[meeber]

@nzakas I played around with it a bit and was able to come up with one potential solution:

Modifying /lib/options from:

        {
            option: "color",
            type: "Boolean",
            default: "true",
            description: "Disable color in piped output"
        },

To:

        {
            option: "color",
            type: "Boolean",
            alias: "no-color",
            description: "Force enabling/disabling of colors"
        },

Produces -h output of:

Output:
  -o, --output-file path::String  Specify file to write report to
  -f, --format String         Use a specific output format - default: stylish
  --color, --no-color         Force enabling/disabling of colors

I tested using each option, as well as no option at all, and it behaved as expected each time.

Thoughts? :D

[nzakas]

@meeber that looks great! Can you submit a pull request?

[meeber]

@nzakas sure thing.