-
Notifications
You must be signed in to change notification settings - Fork 73
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
Support error severity screening option #129
Support error severity screening option #129
Conversation
To view this pull requests documentation preview, visit the following URL: Documentation is deployed and generated using docs.page. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@rrousselGit please review |
What do you think? If you do not accept the changes, please close it. |
' ${_relativeFilePath(error.location.file, workingDirectory)}:${error.location.startLine}:${error.location.startColumn}' | ||
' • ${error.message} • ${error.code}', | ||
); | ||
hasErrors |= error.severity == AnalysisErrorSeverity.ERROR; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't use |=
. This is the |
operator, not ||
.
So the == would be executed even though it's unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed commit 36140d7
|
||
if (hasErrors) { | ||
exitCode = 1; | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to use "return", there's no need for the for loop above to iterate over all errors. It probably should stop as soon as one unignored error/warning/info is found
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed commit 36140d7
I didn't take enough considerations for code efficiency
@@ -72,7 +72,7 @@ void main() { | |||
test_app2/lib/main2.dart:1:6 • Hello world • hello_world | |||
''', | |||
); | |||
expect(process.exitCode, 1); | |||
expect(process.exitCode, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not right. If a lint if emitted, it should emit 1 not 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm considering the following configuration.
- ErrorSeverity.info => Optional error (default exit code 0)
- ErrorSeverity.warning => Default error, but optionally skippable (default exit code 1)
- ErrorSeverity.error => Always error (default exit code 1)
This is consistent with the terminology used in Dart analyze.
modifying the parameter definition here. So it will be changed to return an exit code of 0.
Could you please share your thoughts on the design for this ErrorSeverity? I would appreciate hearing your considerations and insights.
I have contemplated aligning it with the fundamental design of Dart analyzer.
However, I am unsure if it aligns with the overall philosophy of this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer basing custom_lint on flutter analyze
rather than dart analyze
.
With flutter analyze
, infos lead to an exitCode 1 too, and you do flutter analyze --no-fatal-infos
) | ||
]); | ||
|
||
final helloWordPluginSource = createPluginSource([ | ||
TestLintRule( | ||
code: 'hello_world', | ||
message: 'Hello world', | ||
errorSeverity: 'ErrorSeverity.WARNING', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This impacts existing tests.
You should instead make a separate variable with the warning flag instead of reusing something already used by different tests but with the info status.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before considering setting up another test, I would like to confirm this discussion first.
@@ -258,27 +334,27 @@ class _Lint extends DartLintRule { | |||
) { | |||
final line2 = resolver.lineInfo.getOffsetOfLine(1); | |||
reporter.reportErrorForOffset( | |||
const LintCode(name: 'x2', problemMessage: 'x2'), | |||
const LintCode(name: 'x2', problemMessage: 'x2', errorSeverity: ErrorSeverity.WARNING), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why these changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason is the same as here.
@@ -37,6 +38,7 @@ class TestLintRule { | |||
final String onVariable; | |||
final String ruleMembers; | |||
final List<TestLintFix> fixes; | |||
final String errorSeverity; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't use a String for this. Either make an enum or use the official ErrorSeverity object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed commit 8fffd8d
Hello! Sorry for the slow review. The notification was lost in the sea of notifications I receive :( I had another pass at this. It's looking mostly good! But there are some relatively minor issues. Mind fixing them? |
Thank you for maintaining the package, No problem. I will follow your path. |
👋 Do you still plan to work on this? :) |
Oops I may have misunderstood. I expected to be presented with a completely different alternative. Our development team is still waiting for this change. |
👋 I don't quite understand what the confusion is. Do you mind explaining? |
Co-authored-by: Remi Rousselet <darky12s@gmail.com>
await cli.entrypoint(['--no-fatal-infos']); | ||
|
||
expect(err, emitsDone); | ||
expect(exitCode, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you test that out
still logs the infos/warnings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed commit 882b9bb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is looking good!
If you update the tests to check that out
still includes the logs, I'm happy to merge this asap and deploy it :)
Great thanks! I'll wait for the CI to complete and merge this |
Custom Lint is a cool tool and makes my project better.
A few additional features would make the operation easier. This PR will add an option to screen Error Severity.
I implemented this issue on my own since it was a separate issue from #101 .
Any thoughts or policies? If not, I would be happy to have a positive consideration for the merge based on this PR.
My project is going to have a constructive Custom Lint maintenance once this change is in place.