Consider printing violations to stderr and informational logs to stdout

[jpsim]

We currently do the opposite. I just opted to do the same as rubocop, which made sense to me since the main output of a linter ​_are_​ the errors themselves, but I don’t feel strongly about it.

I bring this up because when asked about what someone didn't like about SwiftLint, they replied "It prints junk to stderr for no reason".

@keith brought this up once before in #152 (comment).

[scottrhoyt]

This discussion begs the question of what the output of swiftlint should really be. To me this is just the violations. For example if I wanted to pipe the output of swiftlint to another process, I think I'd only want the violations (e.g. swiftlint lint | grep MyFile.swift). This is largely how is works now.

The informational logs like Linting MyFile.swift ... to me make sense if you were to specify a --verbose, -v flag. In which case they would go to stdout as well.

Finally, errors like config error: ..., Could not read configuration file at path ... or Invalid config for ... should continue going to stderr.

I think this scheme allows for the best selective logging and redirection.

Just my $0.02.

[scottrhoyt]

Although, I understand this would be a pretty big upgrade to the logging functionality as it exists now, though I'd imagine we could find a suitable library.

[jpsim]

The informational logs like Linting MyFile.swift ... to me make sense if you were to specify a --verbose, -v flag. In which case they would go to stdout as well.

The first part makes sense to me, but I'm still not convinced that the informational logs should go in stdout because you if you do that, you can no longer rely on custom machine-readable format reporters (json, csv, checkstyle) to be parseable.

Rubocop handles this by allowing lint output to be piped to a file (its -o option) which then provides 3 places to "log" stuff: stdout, stderr & the file. However, I'm not convinced that this is worthwhile.

[scottrhoyt]

Hmm. I can see both sides to that. I'm primarily thinking about my two use cases.

1. Pipe just violations output to another process (e.g. grep).
2. Allow stdout redirection while still printing only error-level info to the console (e.g. a CI build or benchmarking script).

In both of these cases, I'm a fan of keeping informational logging out of stdout by default. I generally favor keeping it going to stdout and controlling it with a verbosity level, but it would be interesting to hear other points of view on this.

[klaaspieter]

I don't think the informational log provide value at the moment. They just repeat the internal process of the tool, which is an implementation detail anyway. It's very repetitive, makes the output unreadable (or unscannable at the least) for humans and not pipeable without redirection.

I agree with @scottrhoyt that default stdout output should just be the violations. A --verbose flag could be introduced to provide more information which is definitely useful during debugging or when someone wants to report an issue.

I've started working on a new reporter that makes the output a bit more human readable. The output is debatable but, looking at jshint and other similar programs, it's usually something like:

file[n] line, col, warning
file[n] line, col, warning

file[n1] line, col, warning
file[n1] line, col, warning

file[n*] line, col, warning

For now a reporter like this will only be useful when 2>/dev/null. Otherwise SwiftLint will also show the informational logs which are superfluous. I think it makes sense for SwiftLint to default to printing only what the reporter says it should print.

[jpsim]

Thanks for the useful feedback, @klaaspieter! I personally think the Linting MyFile.swift ... logs are very useful to have enabled by default, giving users an idea of the linting progress.

With that in mind, I think we could evaluate either a --silent or --log-level flag.

[norio-nomura]

My thoughts:
Print violations to stdout.
Print error to stderr.
For printing progress, it would be important that can be enable/disable by command line option than it use which output.
I prefer, progress is default off, is on when debugging by command line option. But I do not mind whether default is on or off, if it's controllable.
If progress output would be customizable by .yml or command line option, it would satisfy most users. But I don't need it now.

With that in mind, I think we could evaluate either a --silent or --log-level flag.

👍

[klaaspieter]

Re my comment about a custom reporter. The following does what I want for now:

swiftlint lint 2>/dev/null

It would be nice if the files were separated by newlines, but I'm unsure whether that warrants a custom reporter or not. Either way the 2>/dev/null would be needed to silence the linter process.

[scottrhoyt]

Sounds like the we should continue with the current process and potentially add a --verbose or --silent flag?

[jpsim]

Yeah, my preference is a --silent or --quiet flag.

[jpsim]

A --quiet flag was added to lint and autocorrect in #497. Thanks to everyone for your input here!