-
Notifications
You must be signed in to change notification settings - Fork 732
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
CST explorer? #666
Comments
I'm going to go ahead and try to build a hook that allows a transformer to replace the parsed AST |
Hmm I'm going to need to update |
I absolutely love that I got issue #666 for this bit of devilry : ) |
It's looking like the greatest difficulty in implementing this will be asynchronicity. The important logic is in the |
I think one of the tricky parts is that in my new workflow there would be not one but four main trees:
To accommodate this I imagine making use of the tabs UI element at the top of the tree pane, which likely would mean changing the current JSON tab into a checkbox, which makes sense because all these tabs will show trees which can be rendered as JSON. |
I'm happy to do the work, but I'm very curious to hear from @fkling if this is a direction that the project is interested in going? |
I've spent the last few months working on a tool, cst-tokens, that I believe will serve as a replacement for recast.
The idea of cst-tokens is to implement the basics of code transformation without any language or parser-specific logic. This could give AST explorer the ability to allow users to easily write transforms for every single language it has a supported parser for!
To do this each parser would need an associated cst-tokens grammar. This isn't as much of a problem as it sounds like because those grammars don't need define complete parsing logic. Instead a grammar just expresses (in essence) what the valid ways of printing a given AST might be. The cst-tokens engine can then use the grammar to recombine a given AST with its source text while tokenizing and attaching the tokens to the nodes they conceptually belong to. Because of the way the problem is simplified, a single grammar can be used to support every estree-compliant parser at the same time (including Babel which is only sort of compliant).
While all this is cool, it creates some architectural problems. cst-tokens isn't really a parser itself. It doesn't belong in the list of parsers. When it's active though, it needs to decorate/replace the tree that the active parser has generated. I don't know enough about how the AST explorer code is structured yet to understand what this would take to implement.
The text was updated successfully, but these errors were encountered: