You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our JSDoc scanner currently always scans whitespace and newlines as significant - the constant need to skip or ignore these tokens, then fix up node positions to account for them (or ignore them) is a brittle process - especially as the jsdoc scanner is interwoven with the normal scanner for certain parts of jsdoc parsing, which does make whitespace insignificant. The JSDoc scanner should behave more like the normal scanner or JSX scanner where whitespace is insignificant (and never has a token made for it), and comment text has an alternate scan mode that munches on all text until something indicates the comment's end (for capturing descriptions).
AFAIK, whitespace is captured as a token right now to capture indentation for descriptions; however description start position and the raw text of the description should be sufficient to derive the re-indented value. Descriptions should probably be nodes, like JSXText, with a range and a processed value (kinda like an identifier or a literal) - this way the original source text remains available via the range, but also have a processed value that's has spare blank lines and indentation stripped away (this would help the classifier quite a bit, as it relies on a bunch of implicit structure in the JSDoc parser and AST to capture them today).
The text was updated successfully, but these errors were encountered:
Ref #24184
Our JSDoc scanner currently always scans whitespace and newlines as significant - the constant need to skip or ignore these tokens, then fix up node positions to account for them (or ignore them) is a brittle process - especially as the jsdoc scanner is interwoven with the normal scanner for certain parts of jsdoc parsing, which does make whitespace insignificant. The JSDoc scanner should behave more like the normal scanner or JSX scanner where whitespace is insignificant (and never has a token made for it), and comment text has an alternate scan mode that munches on all text until something indicates the comment's end (for capturing descriptions).
AFAIK, whitespace is captured as a token right now to capture indentation for descriptions; however description start position and the raw text of the description should be sufficient to derive the re-indented value. Descriptions should probably be nodes, like
JSXText
, with a range and a processed value (kinda like an identifier or a literal) - this way the original source text remains available via the range, but also have a processedvalue
that's has spare blank lines and indentation stripped away (this would help the classifier quite a bit, as it relies on a bunch of implicit structure in the JSDoc parser and AST to capture them today).The text was updated successfully, but these errors were encountered: