Update: use doctrine range information in valid-jsdoc

[not-an-aardvark]

What is the purpose of this pull request? (put an "X" next to item)

[x] Changes an existing rule
[x] Add autofixing to a rule

What rule do you want to change?

valid-jsdoc

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

The same amount

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

New default behavior

Please provide some example code that this change will affect:

/**
 * @param {number} a
 * @param {number} notB
 */
function foo(a, b) {}

What does the rule currently do for this code?

It reports the entire JSDoc comment to indicate that the second parameter name is wrong.

What will the rule do after it's changed?

It will report only the text @param {number} notB in the comment to indicate that the second parameter name is wrong.

What changes did you make? (Give an overview)

Now that doctrine can provide range information in JSDoc tags, this makes a few improvements to the valid-jsdoc rule:

• When reporting a specific tag or type annotation, the rule now uses that tag as the report location, rather than reporting the entire comment.
• The rule can now autofix type annotations based on the existing prefer and preferType options (for example, it can replace object with Object if the rule is configured to prefer the latter).

Is there anything you'd like reviewers to focus on?

Nothing in particular

[j-f1]

Would it be possible to only report the notB segment of the comment?

[platinumazure]

LGTM, thanks!

[not-an-aardvark]

@j-f1 Unfortunately, that information is not provided by doctrine because it's a string property of the tag object, so it doesn't have its own range.

[not-an-aardvark]

@platinumazure @ilyavolodin @gyandeeps Thanks for reviewing. To clarify, are you also 👍 for adding this feature? If so, can you add a 👍 to the issue so that we can mark it as accepted?

[ilyavolodin]

Definitely 👍 seems like a significant improvement over current situation.

[not-an-aardvark]

@eslint/eslint-team We need one more 👍 from a team member to accept this issue.

[soruly]

This change does not seem to handle optional array types using []

When eslint rules has a preferType that maps undefined

"valid-jsdoc": ["warn", {
  "preferType": {
    "number": "Number",
    "string": "String",
    "undefined": "Void"
  }
}],

/**
 * @param {number[]} [a=1]
 * @param {string[]} [b=""]
 */
function foo(a=1, b="") {}

The code above should be fixed to {Number[]} and {String[]}, but eslint fixed them to {Void} instead

This is happening since eslint 4.16.0 till 4.18.2

[not-an-aardvark]

@soruly If you've found a bug, please create a new issue and fill out the bug report template. Thanks!