I'd like to list some topics that need to be visited in order to bring jscodeshift out of stagnation. 1. The biggest issue is with recast. This library hasn't really had a lot of maintenance for the last couple of years, and there's something like 150+ issues and 40+ pull requests waiting to be merged. It seems like 80% of the issues that are logged against jscodeshift are actually recast issues. In order to fix the jscodeshift's outstanding issues, either recast itself needs to fix them or jscodeshift will need to adopt/create its own fork of recast to solve them. For the past year and a half or so putout's main developer has been maintaining a fork of recast and adding a lot of fixes to it. It might be worthwhile to look at switching to @putout/recast as opposed to the recast upstream. I've also been working on a fork of @putout/recast for evcodeshift that adds a few other things to make evcodeshift transforms more debuggable in vscode. 2. What can be said about recast can probably also be said to a lesser degree about ast-types. 3. How are existing outstanding issues and pull requests to jscodeshift going to be dealt with? Some of the issues/pull requests are from so long ago that I don't know if they're even relevant any more. Also, too many currently open pull requests is can scare away people who want to contribute. At this point, would it make sense to close most of them? If any can be easily and safely merged as is (after a bit of testing) should we go ahead and do so? 4. In a similar vein, a number of issues really aren't labelled. Is there any issue with retroactively labeling them so we can more easily search for needles of defects in a haystack of feature requests? 5. jscodeshift out-of-the-box uses the "babel5compat" setting, which keeps babel parser changes at pre-babel 6 AST's, which ostensibly seems to be done to avoid breaking old existing codemods. The "babylon" configuration, which targets newer post-Babel 6 features that more and more people seem to be complaining they don't have access to, has to be explicitly specified. At this point, should jscodeshift be switched over the babylon as a default? 6. In a similar vein, would any Facebookers being able to tell me what parser configuration is Facebook internally using for their jscodeshift transforms? babel5compat (the current default), babylon, ts, etc. I'm guessing bad things would happen if a new version of jscodeshift broke Facebook legacy codemods, so I'd like to know what I'm up against. It might be possible to hack together some kind of compatibility auto-detect functionality that scans codemod code to guess which parser to use, but I'd like to see if this even needs to be written before attempting to write it. 7. There's a number of issues in the project that aren't labelled, which makes searching explicitly for defects (as opposed to feature requests) a little more challenging. I assume there should be no issue with labelling them to make them more searchable?