Capturing output

[mikeloll]

As far as I can tell there is no way to capture the output of the linter via normal unix redirects, like > out.txt since the linter raises npm errors which get sent to stderr.

I'm wondering if it would be better to report errors to stdout or at least have an option to do so.

[vsiakka]

This behaviour was changed from @timbru31 so that when you use a ci system like jenkins it can pick up the linter messages as errors. On one hand, I don't think anyone would use json as a human-readable format; stylish is way friendlier so I could change it to output to stdout. On the other hand, that would mean that the formatters are inconsistent in where they output. So, I think the best is to implement an option for saving in a file. I will try to get to it next weekend. Till then you can do: > out.txt 2>&1 To output both stdout and stderr to your file.

[mikeloll]

Yeah, I'm an idiot. I forgot how to capture that. I think the project would do well to emulate a popular linter like eslint. Eslint write to stdout but also returns 1 as the exit code (provided there are errors).

Saving to a file seems like extra work - extra config, extra code, etc. Simply writing to stdout, I think, would make many more workflows possible for your users.

I can do a PR if interested.

I agree about using json for human-readable output. I think stylish is the way to go if you need to read the output. While stderr makes sense from a logic perspective, I think using stdout just enables many more common workflows. Plus it would still work from Jenkins and other CI systems that rely on a 0/1 exit code status.

Thoughts?

[vsiakka]

When I first wrote gherkin lint, it used to output to stdio (I don't remember if I had looked into eslint and copied them, or I used the only console logging a knew as a js noob).

The change to stderr was a specific feature request (see https://github.com/vsiakka/gherkin-lint/pull/41) for functionality that I personally don't use, so I don't want to take it out completely as I can't speak to the usercase it's fulfilling and how big of an issue it would be to take it out.

I agree with you that it makes sense to be more similar to eslint, as it's a very common js linter, so the way we could address this is to make gherkin-lint print in stdout by default, and allow printing in stderr if a flag is specified.

What do you think about this approach @mikeloll, @timbru31 ?

[mikeloll]

Sounds good to me. Or the opposite, whatever. But the flag would be good.

[timbru31]

[...] and allow printing in stderr if a flag is specified.

This sounds good to me. While I've left the project that used Gherkin in the meanwhile, I'm still a big fan of linting in a CI (Jenkins, Travis, GitLab, etc.).
IMO the exit 1 feature is more important than the log level (stdout or stderr) - having it configurable is a plus.

[tali]

I'd also appreciate it if the JSON output would go to stdout. Especially, as other error message are (correctly) written to stderr and currently there is no easy way to separate "gherkin-lint could not run" messages from "gherkin-lint could analyze the feature files and found the following issues". I'd like to automatically show all found issues within the source code and would like to just pass the output to a JSON parser.