8000 Enhancement: [prefer-promise-reject-errors] Extend to AbortSignals · Issue #10717 · typescript-eslint/typescript-eslint · GitHub
[go: up one dir, main page]
Skip to content

Enhancement: [prefer-promise-reject-errors] Extend to AbortSignals #10717

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.

Sign up for GitHub

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

Jump to bottom
Open
4 tasks done
vikingair opened this issue Jan 27, 2025 · 2 comments
Open
4 tasks done

Enhancement: [prefer-promise-reject-errors] Extend to AbortSignals #10717

vikingair opened this issue Jan 27, 2025 · 2 comments
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule evaluating community engagement we're looking for community engagement on this issue to show that this problem is widely important package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@vikingair
Copy link

Before You File a Proposal Please Confirm You Have Done The Following...

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/prefer-promise-reject-errors/

Description

Currently, a user can call AbortSignal.abort("foo") or new AbortController().abort("foo") with anything. But doing so within a fetch request will throw the provided argument. In contrary a AbortSignal.timeout(1234) and new AbortController().abort() will throw a DOMException.

I'd like to ensure that the arguments should be enforced to be instances of Error as well.

It could make sense to extend rather this rule: https://typescript-eslint.io/rules/only-throw-error

Fail

new AbortController().abort("foo");

AbortSignal.abort("foo");

Pass

new AbortController().abort(new Error("foo"));

AbortSignal.abort(new DOMException("foo"));

Additional Info

No response
@vikingair vikingair added enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Jan 27, 2025
@bradzacher
Copy link
Member

I can see value in this as a separate rule -- I don't know if it makes sense to mingle it in with a rule specifically about promises.

I'm personally +0.5 on this -- I think there's value in better standards for this API -- but I also don't think this API is widely-used enough for there to be enough value in us building and owning a rule for it?

cc @typescript-eslint/triage-team

@JoshuaKGoldberg
Copy link
Member

Yeah I have only ever seen AbortSignal used maybe 2-3 times over the last few years. For users of AbortSignal this rule does sound useful, but there just aren't that many of them IME. Maybe: evaluating community engagement, so if folks are using it, they can let us know?

@JoshuaKGoldberg JoshuaKGoldberg added evaluating community engagement we're looking for community engagement on this issue to show that this problem is widely important and removed triage Waiting for team members to take a look labels Jan 28, 2025
@kirkwaiblinger kirkwaiblinger mentioned this issue Apr 23, 2025
Open
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule evaluating community engagement we're looking for community engagement on this issue to show that this problem is widely important package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@JoshuaKGoldberg @bradzacher @vikingair
0