Eslint-plugin-jsdoc: Apply rules to specific line instead of entire block

[ProLoser]

I'm not sure if this is doable but it'd be nice to have slightly more accurate line numbers instead of marking an entire docblock as invalid.

[gajus]

PR welcome.

[bary12]

Notice that the way the code is written right now doesn't allow it. It works with the bare text rather than proper ESlint's AST nodes. This change would require some changes to the core code. In particular, the variable jsdoc in IterateJsDoc.js should be converted to an object containing the nodes. This would allow to report with the node where the problem is, rather than with the node containing the entire docstring.

[brettz9]

I've fixed in check-param-names (the rule in your screenshot), but feel free to report for any other rules with missing or incorrect line numbers.

[gajus]

:tada: This issue has been resolved in version 15.0.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[dietergeerts]

The way this is solved isn't with creating actual nodes. Is this considered in the future? I believe that converting the docblock to actual ast nodes will help building rules for them, and even let other plugins use those.

I'm currently looking into a way to lint swagger yaml definitions that are defined in jsdocblocks with the @swagger tag, which is used by packages to generate the UI for them.

[brettz9]

@ProLoser : Turns out there were a number of other rules with missing line numbers (and a few related to settings that should have been line 1). Fixed through v15.3.2, v15.3.3 and v15.3.4.

@dietergeerts : Given that eslint deprecated their jsdoc support including their own comment parser project (doctrine), I wouldn't think they'd be in favor of exposing such support.

We are, however, parsing comments and their types in a structured manner through comment-parser and jsdoctypeparser, and I think we are only be resorting to one-off regular expressions and such when whitespace is of concern, so if you hadn't noticed these, they may be of use to you.

[dietergeerts]

@brettz9 , thx for the links. I did not dive deep enough in the source code. These packages are on the list now in my search to parse that yaml.