Eslint-plugin-jsdoc: Import used in JSDoc showing as `no-unused-vars`

[kirkstrobeck]

const FooController = require('xyz');

// and below

constructor() {
  super(stuff);

  /** @private @const {!FooController} */
  this.FooController = abc;
}

I’m getting the error eslint(no-unused-vars), how would I show the linter it’s being used?

[brettz9]

Firstly, you must have jsdoc/no-undefined-types enabled, as I presume you already do.

Beyond that though, the problem in your case appears to be that you have @private on the same line as @const. Per the jsdoc site:

Each block tag must be followed by a line break, with the exception of the last block tag in a JSDoc comment.

(at https://jsdoc.app/about-block-inline-tags.html#overview )

(And you can see that at https://jsdoc.app/#block-tags , @private is a block tag.)

So if you put @const on the next line, it can be parsed by eslint-plugin-jsdoc so as to mark the encountered FooController type as used for the purposes of the no-unused-vars rule.

However, if you're not really using FooController, it is sufficient to add it to the globals (or global) comment block, e.g., /* globals FooController */ so you don't need to pollute your code with imports that don't have side effects beyond their use by the linter.

Closing as that should resolve, though feel free to comment further as needed.

[kirkstrobeck]

That was helpful. Thank you!

[kirkstrobeck]

Adding the new lines does fix the issue, however I would like to allow for standalone block-level tags to live alongside each other. Is there any way to support this incorrect syntax?

/** @private @const {!FooController} */

Perhaps some type of rule to allow inlining of block tags that have no additional params, like @private.

[brettz9]

The comment-parser tool we are using expects the line break. And if not, it would have to create and abide by some other (non-standard) rule, such as disallowing @ within a tag description or at least disallowing an unescaped at-sign at the beginning of a block of text.

Though I do see the appeal for it, I don't think these tools, which are general purpose tools to enforce correct jsdoc behavior are the place for non-standard practices. The best I can suggest--unless you were determined to fork comment-parser and our tool to allow the syntax--is to propose that jsdoc itself change its syntax. If they supported it, then I think our project maintainers would be in agreement to allow doing so as well.