-
-
Notifications
You must be signed in to change notification settings - Fork 397
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
feat(linter): implement no-throw-literal
#6144
base: main
Are you sure you want to change the base?
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
3566ef9
to
04dcd09
Compare
CodSpeed Performance ReportMerging #6144 will not alter performanceComparing Summary
|
1961f35
to
76a8b66
Compare
let message = | ||
if is_undef { "Do not throw undefined" } else { "Expected an error object to be thrown" }; | ||
|
||
OxcDiagnostic::warn(message).with_label(span) |
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 we add help text for this? Like:
-
Wrap the value with an error object: `throw new Error(...)`
- or if
undefined
:throw an error object instead: `throw new 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.
Currently, there are many rules that do not provide help, only help prompts when fixable.
Wrap the value with an error object:
throw new Error(...)
For fixable types like string
and template
, they automatically include help suggestions. We've already implemented fixes for some of them, and the remaining ones are largely unfixable, so this prompt might not be necessary.
throw an error object instead:
throw new Error()
For undefined
, this should be a very intuitive error prompt in itself, and perhaps help
is not necessary.
Is there a necessary requirement for adding help
? Under what circumstances should we add it? @DonIsaac
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.
consider this comment as non-blocking. I'm of the opinion that every warning/error should include at least some indication of how to fix it. I think a static message here would be fine too:
.with_help("Throw an Error object instead: `throw new Error()`")
Some diagnostics don't contain help messages, I would consider that something we should fix. From our Linter Rule principles:
- The
message
should be an imperative statement about what is wrong, not a description of what the rule does.- The
help
message should be a command-like statement that tells the user how to fix the issue.
Related to #479