Open JoshuaKGoldberg opened 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.
Expected behavior
Block comments that refer to org-scoped npm packages at the start of a line shouldn't be treated as JSDoc tags:
...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:
ESLint Config
ESLint sample
Environment
eslint-plugin-jsdoc
version: 44.2.7