Check yield and @yields/@yield

[brettz9]

While #271 aims to support yield with require-returns-check (in environments like TypeScript where there is no @yields tag support and thus it makes some sense to use @returns to contain this information), I think a new rule ought to be added for regular jsdoc mode (i.e., not TypeScript or GCC which don't support @yields/@yield) to ensure a yield is present when the @yields/@yield tag is used.

Similarly, I think we need another rule equivalent to require-returns as well, which checks that if a yield is present, that there is a @yields/@yield tag.

And this rule should allow IterableIterator<void> and IterableIterator<SomeType> within @returns as well (for TypeScript/GCC which don't support @yields currently). @returns might perhaps be reserved for the generator return values or if using the actual Generator/iterator such as IterableIterator with a generic/template, then use any return value as the variable portion rather than the yield value.

[golopot]

This will be a seldom used rule. I will accept it if enough people shows interest in it. Otherwise it is better to keep the project small and simple.

[brettz9]

People have already expressed interest by filing an issue, and I would like the same. This is eslint-plugin-jsdoc not eslint-plugin-jsdoc-small-subset-of-tags. Yes, we don't want bloat, but there is no reason we can't meet multiple needs and users can ignore rules they don't want. What is so oppressive about having an extra rule that you don't personally use? We are presumably not just here to meet your or my needs, and we're not talking about some obscure, project-specific rules, but a rule to ensure that the standard tag is documenting as expected.

[gajus]

🎉 This issue has been resolved in version 31.2.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀