-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve output of "rules" command #392
Comments
I like how fastlane handles this:
And then you can run
|
@marcelofabri agreed, I too expected fast lane style output. Although I'm not sure the author column is needed, it kind of works against the notion that anyone can contribute. But the rest of it is nice :) |
Sure, I agree with that. Also SwiftLint doesn't (as far as I know) support parameters as environment variables, do that column shouldn't exist. |
Yes, I'm wholly in favor of this. The |
many improvements to the |
I'm wondering if there are currently any plans to improve the output of the
swiftlint rules
command to help with discoverability. While trying to integrate with SwiftLint, I found myself constantly referring to the source code of the various rules to determine what their defaults were, what the triggered or didn't trigger them etc. The recent addition of opt-in rules complicates things even further.The current output of the rules command is limited to the name of the rule. It's not clear whether or not the rule is enabled by default, or if it has to be opted into.
Some proposals, roughly ordered in (estimated) level of effort:
** Alternatively, make it obvious whether or not a rule is configurable and require that users drill down for more details with something like
swiftlint rules variable_name_min_length --help
If this is something that would be useful, I'd be interested in helping out.
Thank you for your time,
Noah
The text was updated successfully, but these errors were encountered: