Bringing jscodeshift up to date

[Elon Volo]

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?

[Daniel Lo Nigro]

would any Facebookers being able to tell me what parser configuration is Facebook internally using for their jscodeshift transforms?

Usually either Flow or Hermes. I'm not 100% sure if adapters for these parsers are in this repo, but both parsers are available on astexplorer.net.

How are existing outstanding issues and pull requests to jscodeshift going to be dealt with?

Maybe we can close the very old ones if they don't sound relevant any more?

I assume there should be no issue with labelling them to make them more searchable?

This sounds fine to me!

[Michaël De Boey]

@Daniel15 @ElonVolo @trivikr Is there anything I can do to help out to get this project up to date again?

[Trivikram Kamat]

Is there anything I can do to help out to get this project up to date again?

@ElonVolo is driving getting jscodeshift up to date and will respond to your question.

If I was at their place, I would have created issues for each suggestion (if they're not already present) and use GitHub's Project Tables to track a new project (naming it phoenix or jscodeshift returns)

I would have also made releases automated, suggestion in #494, to make the releases more frequent.

[Elon Volo]

Okay, now time for another one of my essay length posts, from most important to least important.

1. I've been on enough rewrite projects named Phoenix to know you should never, ever name your project Phoenix. Can we please avoid the name "Phoenix"? And yes, I'm consider the word to be cursed. :)

2. The biggest challenge facing jscodeshift (other than the documentation that everyone keeps complaining about) is 50-80% of its logged bugs are actually bugs in the recast and ast-types libraries, both of which have a substantial number of bugs and outstanding pull requests, and both of which tend to be updated infrequently. This means there are whole classes of bugs that jscodeshift as a project can't do anything about. At some point, unless something changes with those projects, it's probably going to be necessary to fork both those libraries, put in PR's to upstream back to them, and hope that they'll someday be merged.

3. @trivikr, I agree that all these updates and bug fixes we make are useless to people if we don't regularly publish them to npm. I'm not a Facebook employee (I'm actually cramming for SwiftUI screening tests this weekend so I can hopefully rejoin the ranks of the employed), so I probably don't have access to Facebook's credentials or have the authority to publish stuff to npm or actually know what Facebook's policy about publishing to npm is. So you'll have to refer to @Daniel15 about this one. It would be great if we had something that would let us publish at a regular cadence.

4. The github project tables sound look cool. What advantages do they have over our existing setup? Is their being in beta going to be any issue? (no pun intended) Is there some sort of migration path that would take the users to the new issues table if they click on the "Issues tab"?

5. One of my main priorities is to define concrete list of existing defects that might need to be fixed (if they really are reproducible defects). While a whole bunch of feature requests in the issues section that we'll not be able to implement, but at least we should try to fix existing defects (that aren't recast/ast-type bugs).

So I went through all the issues and closed ones that were ancient or irrelevant because they were fixed and never closed. Everything that remained I made sure had a label (with 1-2 exceptions). I didn't verify that the bugs were reproducable, I just made the distinction that it was reported as a defect.

6. Which is where @MichaelDeBoey's question comes in. We need someone (myself + others) to go through the list of 40+ issues marked as bugs and figure out whether they've been fixed in the most recent version or if they're still outstanding and mark it as such in the comments. If it's an easy fix, by all means fix it, but the most important thing is to make sure that our list of bugs is still relevant.

[List Of Bugs](https://github.com/facebook/jscodeshift/labels/bug](https://github.com/facebook/jscodeshift/labels/bug)

7. I feel we need enhancements to the CONTRIBUTING.md.

Refined bug reports

• The complete code that the person was trying to transform
• The complete code of the transform
• The full CLI command that was typed to do the transform
• The full output that the user was expected
• The actual output the user got, or alternatively the error message that was printed when the transform failed.

jscodeshift issues in large OSS frameworks

We've also had bug reports submitted from people developing projects using large open source frameworks that has jscodeshift baked into them (usually for migration purposes). It was a considerable amount of work learning the open source framework enough to figure out where jscodeshift was supposedly breaking (sometimes it was a bug in the framework), and in some of those cases the custom code that the user was trying to transform wasn't event present (I had to go the OSS frameworks "examples" directory and pick something similar to try to reproduce the error).

I'd like to propose adding something like "if you're having problems with jscodeshift where it's used in framework your project makes use of, please consider pushing up your entire project (or some subset thereof you're allowed to) to a new branch, make it ready-to-go for one of our developers to test, and post the link to it along with any special instructions in your bug report".

[Daniel Lo Nigro]

For bug reports, it's useful for users to link to a basic repro case on https://astexplorer.net/. Doesn't work in all scenarios, but it's great for things that can be reduced down to a few lines of repro code.

so I probably don't have access to Facebook's credentials or have the authority to publish stuff to npm or actually know what Facebook's policy about publishing to npm is. So you'll have to refer to @Daniel15 about this one.

As part of improving the maintenance of jscodeshift, I've volunteered to do that sort of stuff (tagging new jscodeshift versions and publishing them to npm). 😃

It would be great if we had something that would let us publish at a regular cadence.

Do you mean for beta versions, or do we actually want to push stable versions automatically?

[Michaël De Boey]

Another ast-types related issue: #520

It seems to me that an ownership-transfer or fork would be a good idea imo.