gajus / eslint-plugin-jsdoc

JSDoc specific linting rules for ESLint.
Other
1.1k stars 159 forks source link

Parser shouldn't allow consider slash names to be JSDoc tags #1116

Open JoshuaKGoldberg opened 1 year ago

JoshuaKGoldberg commented 1 year ago

Expected behavior

Block comments that refer to org-scoped npm packages at the start of a line shouldn't be treated as JSDoc tags:

/**
 * @ember/debug etc. etc.
 */

...or at least, the default VS Code syntax highlighting doesn't treat them as tags.

Actual behavior

This package does consider them tags. You can see the failures in action in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/65660 -> https://github.com/DefinitelyTyped/DefinitelyTyped/actions/runs/5196271458/jobs/9369812259?pr=65660:

2023-06-07T05:26:07.4195485Z 1> /home/runner/work/DefinitelyTyped/DefinitelyTyped/types/ember/test/debug.ts
2023-06-07T05:26:07.4196193Z 1>   14:1  error  Invalid JSDoc tag name "ember/debug"  jsdoc/check-tag-names

ESLint Config

module.exports = {
    plugins: ['jsdoc'],
    rules: {
        'jsdoc/check-tag-names': ['error', { typed: true }]
    }
};

ESLint sample

/**
 * @ember/debug etc. etc.
 */

Environment

brettz9 commented 1 year ago

You might file an issue with comment-parser, though I'm not sure whether you'll get a response.

We could look to apply @microsoft/tsdoc, but besides being a likely quite large amount of work to refactor jsdoccomment and eslint-plugin-jsdoc (unless tsdoc can be adapted to follow the comment-parser API), I don't know if the tsdoc parser preserves all whitespace as we need.

Although this mentions AST (whereas we might suspect we would need CST, Concrete Syntax Tree to preserve whitespace), the round-trippability goal sounds promising:

The parser reads doc comments as input and produces an abstract syntax tree (AST) as output. This should be reversible: given an AST input (possibly with modifications), the library can regenerate the corresponding doc comment.

(from https://tsdoc.org/pages/intro/approach/ )

Still, I'm not sure I'd be inclined to work on this myself at this point for such an edge case (and not knowing how experimental the parser package might still be). PR would be welcome if existing jsdoccomment and eslint-plugin-jsdoc tests would pass.