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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom Babel transforms #41
Comments
Hi, yes, this would make sense to expose - actually at the moment, I happend to be looking into a similar feature to be added(want to reuse the verification step for additional codemods to run after converting to typescript). Not yet sure how to better expose it as part of the CLI - will start by extending exposed APIs for |
sweet! let me know if you'd like any help developing / testing that |
published new version allowing to pass additional babel plugins to run after converting to typescript |
works really nicely! thanks for pushing that out so quickly. maybe worth documenting that feature / the rest of the JS-based interface in the README? I'd be happy to help with that if you'd like |
馃憢 big fan of this project! Has worked surprisingly well for my use case :)
Though doing a roughly 1:1 syntax translation is nice, I've found that migrations can often involve other more complex codebase-specific transforms (for example, using a slightly altered generic signature for a TS package). Though I could implement these as standalone codemod scripts run after flowts, it would be great if they could be run right in the flowts execution to take advantage of existing features like post-transform Prettier formatting.
I'm imagining this as an option to
convert
/convertFile
where an array of Babel plugins (similar to existing ones liketsTypesPlugin
) can be passed. This could in theory also be supported via the CLI, though not sure if there's an elegant way to pass in transform plugins.I do see that there's several places where
transformAsync
is applied - I personally see value in supporting post-Flow-To-TS transforms though perhaps transforms could be passed for any stage of the conversion process.That all being said, I completely understand if this is out of the scope of this project! Just thought I'd mention as an idea to aid large-scale migrations - feel free to close if you'd like. Thanks!
The text was updated successfully, but these errors were encountered: