Closed ehzhang closed 3 years ago
I think this is a good solution for now, even if it's just for jscodeshift.
In the long term I want parsers and transformers to be more integrated. The current isolation of parsers and transformers is causing confusion and also limits how transformers can be used. Instead I want to make the transformer directly selectable and configurable, including the parsers it supports and should use.
Hi @fkling! Wanted to follow up to see if there was anything else you'd like me to address. Thanks! :)
Sorry, just not finding much time recently.
Looking for a little discussion on approach! I use AST explorer only every so often and most recently I found myself stumbling a bit again when I tried to write a jscodeshift transform, and was only met with the error below:
Here's an attempt to demystify some of this by adding the
module.exports.parser
directly to the code example (with a cute little formatter to automatically inject the "tsx" transformer)Here's a gif of the flow:
https://user-images.githubusercontent.com/3484848/120608590-34d2a500-c406-11eb-86da-6c49c89bc298.mp4
This adds two new configuration options for transformers:
compatibleParserIDs is used in SELECT_TRANSFORMER as an alternative to always resetting the parser when changing the transformer or turning it on. If we are already on a compatible parser, we won't change.
formatCodeExample supports custom formatting/templating for code examples - in the case of jscodeshift, this is used to set the module.exports.parser based on current parser.
In combination, this supports a workflows like: