State of jscodeshift project #482
Comments
|
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.
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 |
|
Thank you @Daniel15 for your response!
Is there a plan to onboard external maintainers for jscodeshift? Along with @ElonVolo and other contributors, may be we can form a collaborator team? |
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 I'm thinking of using jscodeshift in my hobby projects too, like writing one for SolidJS. |
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. |
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:
|
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
Thank you for creating and maintaining evcodeshift fork! |
|
@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. |
I'm digressing here, but TypeScript was already getting popular in 2016/2017. So users did have an equal/better alternative to Flow.
As long as Meta allows contributors to move jscodeshift to new org (say |
|
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
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.
FWIW I've got the 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'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 #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 😄
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 😃 |
@ElonVolo Friendly ping to follow-up on this request.
I think this issue should be resolved after commits from |
The issue was created at #500 |
|
Given there are no new features since Dec 2019 (~3.5 years) and probably workforce downsizing within Facebook:
Personally, I'd love to maintain this project and apply absolutely all
|
|
@o-alexandrov It has been discussed in this issue & #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.
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 |
|
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 |
|
Where I’m at right now is I’m doing a considerable off-line refactor of jscodeshift. There’s years of tech debt that makes the code hard to understand. E.g. “why the heck are they doing this in this block…(2 hours later) “oh, that’s why”. There’s also certain design choices that could be problematic if node.js were to deprecate certain things in the future or if ESM became hyper-dominant.Sent from my iPhoneOn Mar 20, 2023, at 11:13, Michaël De Boey ***@***.***> wrote:
@o-alexandrov It has been discussed in this issue & #500 that @Daniel15 @ElonVolo @trivikr are working towards bringing the project up-to-date
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@o-alexandrov That comment was about the |
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.
The text was updated successfully, but these errors were encountered: