Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upPrint severity (warn/warnings) #310
Comments
dcousens
added
the
question
label
Oct 29, 2015
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@chrisirhc Thanks for opening a thoughtful issue. We've considered this topic in the past, in previous issues. The conclusion last time was that warnings would be a bit confusing; they would print messages to stderr but still return exit code 0, indicating success. This would leave other contributors to later clean up the warnings, or they'd be perpetually ignored. I think it's best if standard continues to return a simple pass or fail, without distinguishing between important and less important rules, or between old and new practices. If/when we introduce breaking changes, we'll do it in a semver major release so users are in control of when they get the new rules. That way, they can fix atomically upgrade standard and fix their whole codebase. |
chrisirhc commentedOct 29, 2015
When transitioning between standard linting styles, I tend to use warnings to indicate good practices for new code using warnings in a temporary .eslintrc file (severity: 1).
It's useful to point out that the code can follow new code styles, without erroring out on old code.
However, in the current version of standard, all messages are treated equally as errors. Would this be valuable for anybody else?
Perhaps instead, it could output, "W" or "E" at the end of a message for errors, just to be backwards compatible with existing reporters?