Skip to content
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

Add severity level for issues #82

Closed
0xtekgrinder opened this issue Oct 2, 2024 · 4 comments · Fixed by #91
Closed

Add severity level for issues #82

0xtekgrinder opened this issue Oct 2, 2024 · 4 comments · Fixed by #91
Labels
C-propossal Category: sumitting RFC or proposal enhancement New feature or request T-format Type: related with formatter

Comments

@0xtekgrinder
Copy link
Contributor

Description

Some rule are more important than others and to show this we can add severity for each rules:
ex: "WARNING", "ERROR", "INFO".

This can let the user know if some rules needs some immediate fixing or not.

When implementing this, we should exit one if there is one error or at least 15 warnings (can be configurable with a flag)

@notJoon
Copy link
Contributor

notJoon commented Oct 2, 2024

Linter behavior shouldn't depend on error count. If that affected by the threshold, it would highly reduce practicality from a Developer Experience (DX) perspective, as developers would need to run the linter multiple times to repeatedly check the linting results.

For emphasis to user, I think visualization are seems best. We could sort or group issues by severity. Perhaps show the most severe issues at the bottom for quick spotting.

Since terminal settings vary and content can be lost if it exceeds the number of lines, it would be good to have a flag option to limit the number of outputs. how do you think about it?

@notJoon notJoon added T-format Type: related with formatter C-propossal Category: sumitting RFC or proposal labels Oct 2, 2024
@0xtekgrinder
Copy link
Contributor Author

I thought a similar design such as solhint as it can be quite useful in ci to allow only a maximum numbers of warnings (by default I think it is disabled). However after this threshold, the warnings are still shown so users doesn't need to run multiple times the linter.

Totally agree with a sorting.

I don't think that is relevant as it is just terminal limitations and don't really see a use case where a developer doesn't wants to see everything ?

@notJoon
Copy link
Contributor

notJoon commented Oct 3, 2024

@0xtekgrinder

Then, this should implement it so that settings are configured through a configuration file (maybe .yaml format?). solhint's design seems like a good approach. 👍

@0xtekgrinder
Copy link
Contributor Author

Yeah could be a good approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-propossal Category: sumitting RFC or proposal enhancement New feature or request T-format Type: related with formatter
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants