Allow for missing @param's or @return(s) with @implements on the block; also possibly for @augments/@extends and @override

[brettz9]

Migrating from #11037 . I've added it here according to this bug format, though I wonder if this particular issue (as opposed to the other valid-jsdoc issue I reported, eslint/eslint#11036 ) indeed really belongs on ESLint as at eslint/eslint#11037 based on the fact that the issue seems to be how ESLint combines the information, rather than any errors reported by doctrine.

What version are you using?

That on https://eslint.org/doctrine/demo/

What JSDoc comment were you trying to parse?

/**
 * Function representing a transparent color.
 * @implements {Color}
 */

(This is as part of the following larger example:)

/**
 * @interface
 * @param {string} name The color name
 * @returns {object} A color object
 */
function Color (name) {}

/**
 * Function representing a transparent color.
 * @implements {Color}
 */
function TransparentColor(a) {}

What Doctrine options were you using (sloppy, unwrap, etc.)?

No options.

What happened? Include output if possible.

While I can't really model this with the demo, I get errors when combining this (e.g., into the likes of ESLint) with checks against an expected @param, @returns, etc.

What did you expect to happen?

There should be no errors.

The JSDoc (for @implements) states:

If you do not document one of the symbols in the implementation, JSDoc will automatically use the interface's documentation for that symbol.

This would suggest that it is expected that with @implements present, values need only be added if they differ from the interface they are implementing.

While JSDoc even states:

You do not need to add the @implements tag to each member of the implementation (for example, the implementation's instance methods).

...it would be helpful if ESLint could at least avoid the error when @implements is explicit on the block. In SVGEdit, we have a number of these real-world uses which are getting unduly flagged, and it would be a maintenance head-ache to have to duplicate parameter and return information on implementing objects as well as on the interface.

(@augments (or its synonym @extends) should probably behave this way as well and perhaps also @override as well.)

Great project name, btw!

[kaicataldo]

Thanks for this issue. We have decided to officially end-of-life JSDoc support in ESLint. As a result, this repository and project will no longer be maintained.

Thanks for understanding and we apologize for any inconvenience.