Open 0xtekgrinder opened 4 days ago
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?
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 ?
@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. 👍
Yeah could be a good approach
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)