fix: insert cause outside wrapping parens in preserve-caught-error#21062
Conversation
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
| }`, | ||
| ], | ||
| invalid: [ | ||
| /* Parenthesized arguments: insertions must land outside the wrapping parentheses (see gh suggestion corruption) */ |
There was a problem hiding this comment.
These added test cases should not be the first test cases as they are special cases for the fixer.
Further the note from the comment "(see gh suggestion corruption)" seems to be missing context. I think "Parenthesized arguments" is enough in this context.
There was a problem hiding this comment.
Moved them to the end of the invalid cases and shortened the comment to just "Parenthesized arguments" — you're right, the extra note didn't add anything.
|
In the future please follow our AI policy which requires an accepted issue first for AI-assisted contributions. |
|
Understood, sorry about that — I read the acceptance criteria too quickly. I'll open an issue and wait for it to be accepted before any future PR here. |
|
I'm able to reproduce this in ESLint v10.6.0, so marking as accepted. |
There was a problem hiding this comment.
Can we add a test case for when there's a trailing token after the parenthesized argument, like this?
try {
doSomething();
} catch (err) {
throw new Error(("Something failed"),);
}There was a problem hiding this comment.
Added — the fixer inserts after the wrapping paren and before the trailing comma, so it comes out as throw new Error(("Something failed"), { cause: err },); which parses fine. Test asserts that exact output.
Prerequisites checklist
AI acknowledgment
What is the purpose of this pull request? (put an "X" next to an item)
[X] Bug fix
What changes did you make? (Give an overview)
The
preserve-caught-errorsuggestions insert, { cause: err }withfixer.insertTextAfter(argumentNode, ...). AST node ranges exclude wrapping parentheses, so for a parenthesized argument the text lands inside the parens and produces a sequence expression:That makes the options object the error message (
"[object Object]") and attaches no cause at all — re-linting the suggestion output reports the same problem again. Thenew AggregateError((errs))variant is worse: the suggested code throws a runtime TypeError because the sequence expression's value isn't iterable.This adds a small
getLastArgumentTokenhelper that walks past the argument's wrapping close-paren tokens (stopping before the call's own closing paren) and uses it in the three argument-appending suggestion paths. Suggestion output is now:Same bug class as #21045 (
no-implicit-coercion, merged a few days ago).Is there anything you'd like reviewers to focus on?
Three new
RuleTestercases assert the exact suggestion output for parenthesized message, parenthesized errors array, and parenthesized message onAggregateError; they fail on the current code and pass with this change. All 52 rule tests pass.