Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Except for return/param rules, most rules should not be limited to functions #214

Closed
brettz9 opened this issue May 8, 2019 · 3 comments · Fixed by #298
Closed

Except for return/param rules, most rules should not be limited to functions #214

brettz9 opened this issue May 8, 2019 · 3 comments · Fixed by #298

Comments

@brettz9
Copy link
Collaborator

brettz9 commented May 8, 2019

Imo, except for return/param rules, most rules (e.g., rules checking types or tag names, e.g., check-tag-names) should not be limited to checking the jsdoc above functions, but wherever there are jsdoc comments (similar to the new require-jsdoc rule).

@golopot
Copy link
Collaborator

golopot commented Jun 25, 2019

Some code examples that should be reported but are missed:

/* eslint jsdoc/check-tag-names: 2 */

/** @typooo {number} */
let a = 4
/* eslint jsdoc/valid-types: 2 */

/**
 * @typedef {!$#@!} .
 */
/* eslint jsdoc/check-alignment: 2 */

/**
     * Hi
 */
class Foo {}

I suggest adding these checks in a major release, with no options or settings change.

@brettz9
Copy link
Collaborator Author

brettz9 commented Jun 25, 2019

Fine by me, and if decided there is a need, we could add contexts later to override.

If this change is done, I think match-description, require-jsdoc, and require-description should default to the same contexts, though keeping the contexts override option, as descriptions are more stylistic and potentially customizable (unlike in your examples) and might be more likely to vary depending on context.

But note that there are a LOT of contexts, e.g., see https://github.com/typescript-eslint/typescript-eslint/blob/861844d727a2ba7f75cdbba2571498078aee2671/packages/typescript-estree/src/ts-estree/ast-node-types.ts , especially if you want to include typescript and JSX as well.

While PR #294 (inspired by #295) added ObjectExpression (and fixed ClassExpression), there may also be some need for special handling in getJSDocComment, e.g., as FunctionExpression, etc. check for comments not only immediately preceding, but in a few ancestors, e.g., if part of a variable declaration, the comment could be here:

/**
*
*/
var a = function () {};

as well as:

var a = /**
*
*/
function () {};

So there'd be a fair amount of work to analyze how those types ought to be checked and do it fairly systematically. Or, there is the option of just doing it as the need arises. Or something in the middle.

@gajus
Copy link
Owner

gajus commented Jun 27, 2019

🎉 This issue has been resolved in version 9.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@gajus gajus added the released label Jun 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants