jscodeshift
jscodeshift copied to clipboard
facebook
State of jscodeshift project
First off, let me say thanks for the work on this awesome utility. jscodeshift has helped me do amazing things I had never thought possible.
So now I've got the off my chest, here's my question: would anyone be able to tell me what the current state of maintenance is in the jscodeshift project? I see there's 24 Pull Requests, at least some of them with no objections/comments, and that contain capabilities/information that could be useful for the project (like documentation, etc). But these haven't been merged. In some cases for months (years?).
I have some projects that rely on jscodeshift and I need new functionality in jscodeshift to accomplish my goals. I'd love to contribute some of this functionality back into jscodeshift as way of meeting those needs, but if PR's I put in are going to languish for months (or forever) then that's not a route that can work for me and I'll probably have to make more of an official fork and try to build a base of contributors to keep it maintained and get bug reports (in addition to the bug reports I abscond with from upstream). jscodeshift would of course be welcome to integrate my changes/bugfixes back upstream, but I'd prefer to avoid the duplication of effort and extra maintenance headache in the first place.
Does Meta have any plans to revisit jscodeshift in the future? Are they writing some new tool for codemods, or is there some tool that's gaining popularity that I haven't heard about that's expected to take over jscodeshift's marketshare and does everything that jscodeshift does?
I apologize if my inquiry sounds jerky (that's not my intent), but I need to figure out what my next steps are with regards to some of the things that I'm building. I'm sure there's probably a lot of user-facing high business value work at Meta that the existing jscodeshift maintainers probably have to deal with before they even get to touch jscodeshift, so I understand completely if the existing work constraints have presented a challenge to getting time to work on the project.
Again, thanks for all the hard work on the project, and I hope jscodeshift will long be able to handle whatever crazy new things the JavaScript ecosystem throws at it in the future.
cc @mroch who performed the latest v0.13.1 GitHub release.
cc authors listed on npm artifact: @Daniel15 @yungsters
This is a good question! As far as I know, jscodeshift is mostly "community maintained" at Meta at this point, after its main developer left the company a while back. jscodeshift is still widely used across a lot of teams and works as-is for many teams' use cases, so we haven't really needed many more features. I'm not aware of anyone actively working on adding new major features at the moment.
Personally for my own use cases, jscodeshift has been totally fine and I don't really need any extra features.
Are they writing some new tool for codemods
I've heard about ideas for new tools over the years, but I don't think I've actually seen one in use (although it's possible that it exists and I just don't know about it). I think Flow had an idea of building some sort of support for codemods into Flow, but that would have needed to be OCaml which is a barrier to entry for JS developers (and also probably wouldn't play well with TypeScript).
One of the major issues we have with jscodeshift codemods today is that they're not type-aware. For example, it's tricky to only codemod calls like foo.bar() where foo is a particular object type. Adding a deep integration into Flow and TypeScript would be really useful.
Thank you @Daniel15 for your response!
jscodeshift is mostly "community maintained" at Meta at this point.
Is there a plan to onboard external maintainers for jscodeshift? I've built my hackathon project for AWS SDK for JavaScript codemod scripts using jscodeshift in aws-sdk-js-codemod and I'm be willing to help.
Along with @ElonVolo and other contributors, may be we can form a collaborator team?
Is there a plan to onboard external maintainers for jscodeshift?
I'll see if I can find the right person to ask about this and let you know!
I'll see if I can find the right person to ask about this and let you know!
May be I'm asking too soon, but is there any update on this request @Daniel15 ?
We've now moved aws-sdk-js-codemod to awslabs org, and I have plans to get invested in jscodeshift ecosystem further, like creating a custom playground.
I'm thinking of using jscodeshift in my hobby projects too, like writing one for SolidJS. It would be very helpful if we create a team of maintainers outside of Meta to make jscodeshift active again.
May be I'm asking too soon, but is there any update on this request @Daniel15 ?
I'm still waiting to hear back from other teams that are more involved with the ownership of jscodeshift than I am.
Because I needed more functionality/bugfixes for my logitall project and I couldn't wait on jscodeshift to accept new PR's, I ended up forking off jscodeshift into evcodeshift.
https://github.com/elonvolo/evcodeshift
I updated docs, added a few features, and switched to @coderaiser's fork of recast that's fixed some stuff in recast that was causing some unit tests on logitall to break.
Because I needed more functionality/bugfixes for my logitall project and I couldn't wait on jscodeshift to accept new PR's, I ended up forking off jscodeshift into evcodeshift.
I updated docs, added a few features, and switched to @coderaiser's fork of recast that's fixed some stuff in recast that was causing some unit tests on logitall to break.
Yeah, I saw your fork :)
I'm hoping we can merge all the changes in your fork into jscodeshift so you don't have to maintain your own fork. I'm still waiting to hear what some other people think of adding external maintainers.
You can also switch to 🐊Putout code transformer, it has support of:
- ✅ configuration;
- ✅ declarative API based on 🦎PutoutScript
- ✅ simplest possible testing;
- ✅ good maintenance, I’m always here to help you with any codemod, you need;
- ✅ 🐊Putout Editor;
- ✅ Autofixable rules
@putout/plugin-putoutthat helps you to write codemods;
I'm still waiting to hear what some other people think of adding external maintainers.
Revisiting after a week. Any update from jscodeshift owners from Meta on this request?
My prediction:
I’m guessing there might be a fair amount of stagnation in the project until some crisis at Meta arises from a jscodeshift transform gone bad. Because someone will use the babylon parser for an important customer-facing project and jscodeshift didn’t fix the variable declarator problem (which evcodeshift is fixing, BTW). And the postmortem will find that the root cause analysis will be that jscodeshift hasn’t really been maintained by any stable entity in the company for years, which is probably what the people still at Meta who have still been tangentially involved with the project and have been trying to maintain the project in their limited free time have been desperately trying to tell their higher ups at Meta.
After the conclusion of the post-mortem, someone high in management will bang their fist on a table and mandate that jscodeshift be immediately rewritten, with at least a dozen devs on it, in Typescript, and named something completely different than jscodeshift because glory points for new projects.
While the new Typescript codemod project Meta spins up will aim to be a replacement for jscodeshift, it will start getting bogged down in Second System yak-shaving because the table-pounding dude didn’t include a mandate that it would be a boring uninteresting port in Typescript that would ruthlessly limit scope to only doing what jscodeshift needed to do. As opposed to trying to solve every langauge problem that JavaScript has had for the last 20 years, which is what Strikeforce Codemod will try to do. And it will drag out for at least a year.
And for at least a year we’ll be left with an increasingly unmaintained jscodeshift, an up-to-date evcodeshift fork, Putout, and probably whatever the Rome Tools people think up.
This is a great summary @ElonVolo
And for at least a year we’ll be left with an increasingly unmaintained jscodeshift, an up-to-date evcodeshift fork, Putout, and probably whatever the Rome Tools people think up.
Thank you for creating and maintaining evcodeshift fork! I'll mostly shift aws-sdk-js-codemod to wrap over evcodeshift once we prioritize working on it.
@ElonVolo You're almost right. In this case, literally no one in management cares about the state of this project, nor will they. You only have to look at what happened with Flow and it's lack of community engagement. When I was at Facebook I was one of the people who volunteered to help keep this project alive and I literally did nothing in the 2+ (?) years that I had access to it. This project is maintained on a voluntary basis through the good nature of those that contribute. There is no team in charge of this, no managers/directors/VPs that care about what happens to it so long as it can continue to suit their internal use cases.
At best, any contributions here would barely count towards someone's self review, especially if working on it consumed time that could have been spent on more "impactful" projects. Have you looked at reactjs/react-codemod? It hasn't been updated in two years and if you try to use it against the latest Typescript it will crash. Once something has achieved its main function people have to move on to the next thing, and the next, and the next.
You only have to look at what happened with Flow and it's lack of community engagement
I'm digressing here, but TypeScript was already getting popular in 2016/2017. So users did have an equal/better alternative to Flow. When I checked for codemod toolkits before starting work on aws-sdk-js-codemod in Feb 2022, jscodeshift was still the most popular codemod toolkit out there.
There is no team in charge of this, no managers/directors/VPs that care about what happens to it so long as it can continue to suite their internal use cases.
As long as Meta allows contributors to move jscodeshift to new org (say jscodeshift/jscodeshift) it should be fine.
If not, users will either have to start contributing to fork like evcodeshift, or switch to alternatives like putout.
Sorry for the delay. Still trying to figure out things here. I'd personally love to see jscodeshift have some community maintainers, but I can't actually make that decision - it depends on the team that currently owns jscodeshift, so I'm somewhat limited in what I can directly do.
Perhaps it'll get community maintainers. Or maybe it'll move to a community-maintained Github org. Or maybe it'll end up like fixed-data-table where there's a 'blessed' fork? I'm not sure yet. fixed-data-table was different in that there was a replacement in react-virtualized, which is one of the reasons why it was archived.
You only have to look at what happened with Flow and it's lack of community engagement.
It's tricky though, given the maintainers of some projects are primarily focused on internal use cases and in some cases it's very hard to divide time between the community and focusing on internal use cases. As far as I know, TypeScript has far more maintainers, which definitely helps.
Would it be better to not release things as open-source at all? IMO, having code released as open-source (by any company) is still beneficial even if there's no guarantees, as long as the project goals, including any limitations on support, are stated upfront. Most open-source licenses do say that the code is provided as-is with no warranty. There's several open-source projects I personally use that have not been updated in 5-10 years. They still do their job. This is much more common outside the JS community (for example with some Linux tools), since JS is still moving quite fast whereas other systems change a lot slower (so apps written 10 years ago still work).
One idea I've seen is that some types of projects would be better posted as research projects or example code, where the source is publicly available with an open-source license, but there's no guarantee of support. Essentially just "here's some code you might find interesting". Not saying that's the right thing, just that it's been suggested as an option for certain types of projects.
As long as Meta allows contributors to move jscodeshift to new org
FWIW I've got the codemods Github org (currently unused) for this but as of yet haven't actually used it for anything.
Note that this entire comment is just my personal opinion.
So I spoke to more people internally and pushed on it a bit, and I've gotten approval to add @ElonVolo as a maintainer, if he's happy with that of course 😊 I'd love to see the improvements in evcodeshift merged back into jscodeshift, so that the jscodeshift community isn't split between multiple forks.
I'll also take over some of the admin stuff such as cutting new releases and publishing them to npm. Previously this wasn't done consistently - for example the previous few releases were each done by a different Meta employee.
Thanks for pushing on this, @ElonVolo and @trivikr!
Thank you @Daniel15 for following up on this request!
I think this issue can be resolved after:
- @ElonVolo accepts and takes up maintainer work
- The commits from
evcodeshiftare merged injscodeshift, and former one is deprecated on npm.
WDYT?
@trivikr Yeah, that sounds good to me! I messaged @ElonVolo via Twitter DM earlier today too but haven't heard back yet.
I'll also take over some of the admin stuff such as cutting new releases and publishing them to npm. Previously this wasn't done consistently - for example the previous few releases were each done by a different Meta employee.
I've added a feature request to enable automated releases using changesets in https://github.com/facebook/jscodeshift/issues/494
Do comment on it if it looks good to you or if you have alternative suggestions for automated releases.
Thanks @Daniel15 for looking into this, and I'd be happy to be a community maintainer on the project! Not having to moderate/curate large amounts of changes between two codebases would definite make my life easier.
I'll put together a list of reasonable engineering/project management challenges that need to be overcome to stabilize and modernize the project and then share those on this thread (it's a rather long list).
But to shoot the elephant in the room, the biggest issue is going to be with recast/ast, because it is the beating heart of jscodeshift and the source of a great deal of many of jscodeshift's reported bugs. And those bugs can only be fixed at the recast level. And at this point the recast project seems semi-maintained and I believe there's a lot of PR's for bugfixes that are just languishing or are being merged in very slowly.
The other prominent project that does sort of the same things that jscodeshift, Putout, actually had to reluctantly fork recast into @putout/recast and Putout's main developer has had to maintain and add stuff to their fork for the last 12-18 months. Incidentally, Putout's fork is what I use in evcodeshift because stock recast had a bug that kept breaking my unit tests on my logitall project. jscodeshift might need to create its own fork of recast or join forces with Putout to maintain and expand @putout/recast's capabilities.
recast is the biggest pain point for us internally as well. all of Meta's files are formatted with prettier; directly using prettier to print the AST instead of recast would be an option for people in a similar prettier-ified boat. whether to enforce that could be a good discussion to have (in a new thread)
@ElonVolo Can you please sign the CLA (https://code.facebook.com/cla)? Then I can add you as a maintainer 😄
I'll put together a list of reasonable engineering/project management challenges that need to be overcome to stabilize and modernize the project and then share those on this thread (it's a rather long list).
This is a great idea :)
I submitted it last night. Did it not go through?
Sorry, I completely missed that! I do see it now. I just sent you an invite to become a maintainer 😃
I'll put together a list of reasonable engineering/project management challenges that need to be overcome to stabilize and modernize the project and then share those on this thread (it's a rather long list).
@ElonVolo Friendly ping to follow-up on this request.
I think this issue can be resolved after:
- @ElonVolo accepts and takes up maintainer work
- The commits from
evcodeshiftare merged injscodeshift, and former one is deprecated on npm.
I think this issue should be resolved after commits from evcodeshift are merged in jscodeshift as this issues has had long discussion and actions are taken. A new issue or a project can be created for modernizing jscodeshift.
A new issue or a project can be created for modernizing jscodeshift.
The issue was created at https://github.com/facebook/jscodeshift/issues/500
Given there are no new features since Dec 2019 (~3.5 years) and probably workforce downsizing within Facebook:
- would you be willing to let the community to take ownership of
jscodeshiftfromfacebook?- in other words, marking this repo as
archivedand pointing to another repo (forked or new repo preserving all history), where community would actively maintain this project with a reference to all authors
- in other words, marking this repo as
Personally, I'd love to maintain this project and apply absolutely all Facebook's wishes (new features & bugfixes) as well as copy all GitHub Issues from this repo into a new one and resolve the open issues manually one by one.
- my only request in return would be to mark this repo as archived and point with a link to the to-be-forked repo
@o-alexandrov It has been discussed in this issue & https://github.com/facebook/jscodeshift/issues/500 that @Daniel15 @ElonVolo @trivikr are working towards bringing the project up-to-date
Yes, basically what @MichaelDeBoey said. I'm not doing a lot of work for jscodeshift at the moment (in particular I'm not doing any development), but I can merge pull requests and I've got permission to push new releases to npm.
in other words, marking this repo as archived and pointing to another repo (forked or new repo preserving all history), where community would actively maintain this project with a reference to all authors
What do you feel would be the advantage of moving the repo vs keeping it where it currently is? A community member has already been added as a maintainer (@ElonVolo), and other projects like Jest have a great community of contributors even though the repo is still in the facebook org. If there's a good reason for moving the repo, we can consider doing so - I've got the https://github.com/codemods org for this purpose. 😃
Moving vs keeping the repo together with archived mark and external link are all compensation means to drive contributors interest.
Hopefully, currently involved parties are interested and the discussion that started more than a year ago would materialize into new releases.
Just fyi @MichaelDeBoey also proposed ownership transfer in #500
For example, it would be a lot easier for Putout by @coderaiser to promote his library, if instead he would took over jscodeshift and this repo would acknowledge it.