Feature request: More informative output
Currently the output of running $ scss-lint is just the error lines. No error count. No message if there are no errors. It would be nice to have:
- An error count if there are errors
- A success message of there are no errors
- An error raise if there are errors, to trigger a failed build on CI tools like CircleCI or TravisCI
Hey @adsteel, thanks for suggesting ways we can improve the tool.
I'll answer each of your points separately
- An error count if there are errors
Error count is easily obtainable by counting the lines of output with the default formatter, e.g. scss-lint ... | wc -l.
- A success message of there are no errors
This default behavior is the standard for most tools. If there is nothing interesting to report, scss-lint should say nothing interesting.
- An error raise if there are errors, to trigger a failed build on CI tools like CircleCI or TravisCI
The tool already returns a non-zero exit status if errors are reported (see the exit codes documentation), and thus will trigger failed builds in CI.
This default behavior is valuable for integration with other tools. I am completely open to accepting a pull request adding a new formatter that adds the additional information you request, but I don't see it as a common use case for the tool, especially if you're using it the way it was intended, for example via Overcommit git hooks or in CI where all you care about is pass/fail status.
Thanks!
@sds Thanks for the quick response. I built a script to do all of that, but I was expecting a more informative output out of the package a la Rubocop, ESlint or RSpec. I wouldn't say that the current behavior is standard for most tools, given the two primary linters used have informative output. I may open a PR for that, but I may not and it seems like a worthwhile feature to leave an issue open for.
I also had to explicitly program the exit code in my script, otherwise the build passed on CircleCI, so whatever is happening inside scss-lint isn't bubbling up and actually triggering a failed build.
Ok, I'm fine to leave this open. Thanks for providing examples of other tools which default to this behavior.
Regarding:
I also had to explicitly program the exit code in my script, otherwise the build passed on CircleCI, so whatever is happening inside scss-lint isn't bubbling up and actually triggering a failed build.
There must be a problem with your build script. For example, with bash you need to specify the -e flag to make the script fail after the first command returns a non-zero exit status. scss-lint definitely returns non-zero when it fails as of version 0.43.2 (I've just confirmed), so if you're seeing otherwise please provide a reproducible case in a separate issue. You can check the exit status by running echo $?.
Thanks for reopening. I just realized the build was passing because I was printing the error count afterward, which was probably overriding the error code returned.
@sds Have you had a chance to review the PR for this?
Thanks for the reminder, @adsteel. I had looked at this initially and was promptly distracted.
My concern with this is that this breaks SCSS-Lint's integration with Overcommit, since Overcommit uses SCSS-Lint's default formatter.
However, I agree this change in default output is valuable, so we might as well bite the bullet. I just need to find some time to dig in and create a new formatter which behaves like the existing default formatter, and then update Overcommit to use that instead (or, alternatively, switch Overcommit to use SCSS-Lint's JSON formatter). Regardless, it will cause people using Overcommit/SCSS-Lint to have to upgrade due to the breakage.
Thanks for your patience. This will get merged eventually.
I think it would be preferable to switch overcommit to the JSON formatter rather than introduce a new one if that isn't too much work--as long as it can maintain good, human-readable output.