Allow JSDoc make arrow parens needed

[tiansh]

What rule do you want to change?

arrow-parens: "as-needed"

Does this change cause the rule to produce more or fewer warnings?

Fewer

How will the change be implemented? (New option, new default behavior, etc.)?

Prefer new option, make default should be fine too.

Please provide some example code that this change will affect:

/*eslint arrow-parens: ["error", "as-needed"]*/

const f = (/** @type {number} */a) => a + a;
f(42);

Demo

What does the rule currently do for this code?

3:33 - Unexpected parentheses around single function argument.

What will the rule do after it's changed?

No error.

Are you willing to submit a pull request to implement this change?

Not.

---

My IDE seems do not know type of variable a in (/** @type {number} */a) => a if the braces are omitted. I want to make JSDoc a exception of validating arrow-parens: "as-needed".

[mdjermanovic]

I'd support an option to allow existing parentheses if there are any comments inside.

[anikethsaha]

I would like to work on this.

Here is what I am planning as @mdjermanovic suggested to have an option for this.
options name : requireCommentsParams
It will check for comments in params. It will warn only when

• no comments are passed
• When empty comments are passed

Example:

/*eslint arrow-parens: [2, "as-needed", { "requireCommentsParams": true}]*/

const f = (/** @type {number} */a) => a + a;   // correct
const f = (/* */a) => a + a;    // Incorrect
const f = (a) => a + a;    // Incorrect

Though I would even back this without having a separate option for it but having a separate option is good for initial stages then move to default

Rough Implementation

PS: just found out, Espree doesn't have leadingComments and trailingComments node in AST. IDK how astexplorer is able to transform using babel-eslint. In fact, espree doesnt parse comments at all (which seems good for speed, ) So i don't think this kind of enhancement can be possible..

Please correct me if I am wrong !

cc @kaicataldo @mdjermanovic

[kaicataldo]

@anikethsaha Thanks for being willing to work on this. Please note that this proposal hasn't been accepted yet, and we generally recommend that you wait until an issue has been accepted before implementing (to avoid throwaway work).

Regarding handling comments, ESLint doesn't use (leading|trailing)Comments any more (this behavior was dropped in v4. ESLint now handles comments in the context of tokens, rather than the AST. In addition to the AST, Espree also returns a top-level tokens and comments key, and ESLint uses these arrays to create a token store that powers the the token-iteration APIs. Please check out the docs here on more information for handling comments.

[anikethsaha]

@anikethsaha Thanks for being willing to work on this. Please note that this proposal hasn't been accepted yet, and we generally recommend that you wait until an issue has been accepted before implementing (to avoid throwaway work).

Sure ! I will wait till it gets accepted.

Please check out the docs here on more information for handling comments.

Thanks for the link !
I Will check that 👍

[mdjermanovic]

I think there is no need to check if the comment is not empty, just whether there is at least one comment between ( and ), so all of the following would be allowed:

const f = (/**/a) => a + a;

const g = (//
    a) => a + a;

const h = (a/**/) => a + a;

const i = (a/**/,) => a + a;

const j = (a //
    ) => a + a;

[anikethsaha]

const g = (//
    a) => a + a;

const j = (a //
    ) => a + a;

I see, these cases do make sense to keep it as it is 👍

Lost of comments is not so great options especially for use cases like jsdoc
I would back this enhancement as it seems required

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[mdjermanovic]

I'll champion this.

[kaicataldo]

@mdjermanovic Are you still championing this? If so, I think we need to try to reach consensus on its approval. It's been open for quite a while now.

[mysticatea]

It looks like a bug to me. Autofix should not remove comments accidentally.

[mdjermanovic]

There is indeed the autofix bug, and there is this request to not warn at all about unneeded parentheses when there's a comment inside (if the new option is set or as the new default behavior).

Is it accepted to not warn at all, as the new default behavior (no option) which would solve both the bug and this issue?

[anikethsaha]

I think it should be default behavior cause removing of comments seems bug right?

[golopot]

Aside from the autofix bug, the removal of the parentheses changes the semantic under TypeScript --checkjs type checking.

// The type annotation applies to parameter x.
const f = (/** @type {string} */ x) => x

// The type annotation applies to the arrow function expression.
const f = /** @type {string} */ x => x

[mdjermanovic]

I think it should be default behavior cause removing of comments seems bug right?

Yes, but the bug can be fixed by modifying the fixer to remove just parens and keep everything inside, or more likely by not doing the autofix if there are any comments inside (given the @golopot's comment).

This is different from not reporting the error at all. Which is also fine, just wanted to doublecheck what's exactly accepted.

[anikethsaha]

yeah IMO, not to warn should be the default behavior.

[mysticatea]

@mdjermanovic

Is it accepted to not warn at all, as the new default behavior (no option) which would solve both the bug and this issue?

Personally, yes.

If there is a comment in a parameter list, I think someone intentionally did so, therefore the relative comment location should be kept. Removing parentheses of a parameter list moves the relative comment location from "before a parameter" to "before a function". We cannot remove the parentheses along with keeping the "before a parameter", so I think the parentheses are needed.

[mdjermanovic]

Agreed, thanks for clarifying!

[anikethsaha]

Is anyone working on this? if not, I can work on this 👍

[mdjermanovic]

Is anyone working on this? if not, I can work on this

Most likely not, feel free to work on this!