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

Rule to report invalid inline jsdoc tags #1201

Open
ST-DDT opened this issue Feb 11, 2024 · 5 comments
Open

Rule to report invalid inline jsdoc tags #1201

ST-DDT opened this issue Feb 11, 2024 · 5 comments

Comments

@ST-DDT
Copy link

ST-DDT commented Feb 11, 2024

Motivation

I recently discovered that one of my jsdocs was broken due to missing inline code blocks.

 * @param options.includeNonStandard Whether to include a @yearly, @monthly, @daily, etc text labels in the generated expression. Defaults to `false`.

When hovered, this shows like this in vscode:

grafik

The same behavior is visible, when viewing at the TS-AST.

Current behavior

I couldn't find a rule here that reports unknown tags or typos in tags.

Desired behavior

A new rule/options that checks which jsdoc tags exist and check them against a (possibly configurable) allowed list of tags.

Alternatives considered

I tried using

'jsdoc/require-asterisk-prefix': 'error',

but sadly that doesn't detect this kind of error either.

@brettz9
Copy link
Collaborator

brettz9 commented Feb 11, 2024

The rule check-tag-names checks for known tag names in the block position for tags.

Where you are putting the tags, TypeScript (and thus VSCode) expect escaping; the display issue is therefore not related to invalid tag names. You can either add a backslash in front of the @ or enclose the full tag names in backticks.

If you still want to check inline tag names, indeed check-tag-names does not do so. One problem if such a rule were to be added is that one couldn't be sure they were actually intended as tag names (it could be some other use of the at sign). The original JSDoc standard expects inline tags to be surrounded with curly brackets, e.g., {@link someURL} (see, e.g., https://jsdoc.app/about-block-inline-tags#examples and https://jsdoc.app/tags-inline-link and https://jsdoc.app/tags-inline-tutorial ). We could check that this form of link is one of the recognized tags allowable inline, but otherwise, I think it gets tricky.

@ST-DDT
Copy link
Author

ST-DDT commented Feb 11, 2024

Where you are putting the tags, TypeScript (and thus VSCode) expect escaping; the display issue is therefore not related to invalid tag names. You can either add a backslash in front of the @ or enclose the full tag names in backticks.

I don't want those to be jsdoc tag things, those are supposed to be code pieces that just happen to have the code blocks forgotten.

We have check-tag-names enabled and also tried require-asterisk-prefix, but it doesn't report these either.

I would like to have a way to mark these inline jsdoc tags as invalid (or needing wrapping) e.g. like this:

grafik

Does this explain my feature request better?

@ST-DDT ST-DDT changed the title Rule to report unknown jsdoc tags Rule to report invalid inline jsdoc tags Feb 11, 2024
@brettz9
Copy link
Collaborator

brettz9 commented Feb 11, 2024

Yes, that helps clarify. And, \@someTag would also not be reported since it is already escaped, but you want to consider @someTag as invalid if not escaped in the manners discussed.

I'm not sure we want such a rule to apply everywhere, at least if not in typescript mode, since @ may have other uses (e.g., for email addresses) and the original JSDoc standard does not insist on escaping for it, but I think it would be a helpful rule.

@ST-DDT
Copy link
Author

ST-DDT commented Feb 11, 2024

a@yearly doesn't get picked up as jsdoc tag. Only if it has a leading whitespace.

grafik

@brettz9
Copy link
Collaborator

brettz9 commented Feb 11, 2024

Ok, but there is still the likes of @nodejs for a X/Twitter handle. What I am suggesting is to apply the rule for typescript mode, the default, so it should normally be applied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants