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

feat(linter): implement no-throw-literal #6144

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

shulaoda
Copy link
Contributor

Related to #479

Copy link

graphite-app bot commented Sep 28, 2024

Your org has enabled the Graphite merge queue for merging into main

Add 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.

@shulaoda shulaoda marked this pull request as ready for review September 28, 2024 14:07
@github-actions github-actions bot added the A-linter Area - Linter label Sep 28, 2024
Copy link

codspeed-hq bot commented Sep 28, 2024

CodSpeed Performance Report

Merging #6144 will not alter performance

Comparing shulaoda:feat/no-throw-literal (a00d04a) with main (02fedf5)

Summary

✅ 29 untouched benchmarks

let message =
if is_undef { "Do not throw undefined" } else { "Expected an error object to be thrown" };

OxcDiagnostic::warn(message).with_label(span)
Copy link
Collaborator

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()`
    

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linter Area - Linter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants