-
Notifications
You must be signed in to change notification settings - Fork 23
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
Provide a Babel AST mapper #99
Comments
@jaydenseric can you point me to the exact spec, so I know for sure what you are asking for. I couldn't spot it from quick look into babel spec doc |
The https://github.com/babel/babel/blob/main/packages/babel-parser/ast/spec.md#node-objects |
@jaydenseric is this example doing what you are looking for? I am still not sure if this should go into comment-parser itself, but hopefully parsed data provides all you need just in slightly different format |
@jaydenseric let me rephrase my last comment. Is |
@jaydenseric this is all about 1.0 branch, check out its README, it should answer some of your questions above. Having The structure is
all result types live in primitives.ts. |
|
As promised, here is the https://github.com/jaydenseric/jsdoc-md/blob/v9.0.0/private/getJsdocBlockTagSpanCodeLocation.js A JSDoc block tag "span" is a chunk of syntax that holds actual (sometimes multiline) content, vs whitespace separators. The, tag name, type, name group, and description are spans. |
@syavorsky how can I figure out a start and end code location for the main JSDoc comment description? Is it possible just by looking at the comment This is needed to solve jaydenseric/jsdoc-md#19 . |
Can we please add a |
Take a look at the Block.source items up to the first tag line. You can find where tags start by matching Block.tags[0].source[0].number |
Ok, so this took about a week of work to get right in
Of of several gotchas is that This is not too bad for my use case because markdown content looks better with pointless newlines trimmed anyway. But if you needed a description to be exact for some reason (including start and end newlines), you're in trouble. Overall, honestly speaking, it's been a nightmare trying to figure out line and column source code locations for the things
|
Added a few more details to the last comment in edits. |
Although it looks like ESLint-friendly AST would the same as Babel in the case of adding custom types, It would also be nice to support exporting (Ideally this would also allow optional specification of a jsdoc type parser, like catharsis, jsdoctypeparser, or jsdoc-type-pratt-parser, so that in addition to the raw types, one could also get parsed types, with its VisitorKeys being reexported.) |
As discussed in #117 , I've released https://github.com/es-joy/jsdoccomment which converts comments (with comment types) alone to Babel AST (neglected to mention here), and https://github.com/es-joy/jsdoc-eslint-parser (however inefficiently) iterates all nodes to add a Note that the detection of the comment for a given structure is not a trivial matter. For example, with: /* A */
const /* B */ aFunc = /* C */ function () {}; ... for the function expression, we might look for the JSDoc Block at point C first, but then if not present, look for it at point A. My parser uses such an algorithm, and this may currently result in the same (I've added this explanation to the parser README and also updated FWIW, here is the basic structure:
And the jsdoctypeparser types behave as in jsdoctypeparser, but I have renamed their node Note that this is all fairly experimental, and may change. We may also need some pointing to where the jsdoc block actually is present, and the user's indent is not currently preserved. But I thought the AST does at least get us started in allowing any possible precise targeting that might be desired, from individual tag lines to even multi-line types as well as descriptions--preserving all the detail |
Btw, I'm also thinking of removing |
Provide a way to map the parser output into Babel AST as suggested in #93.
The text was updated successfully, but these errors were encountered: