Announcement: Maintenance and Future Plans

[Daniel15]

There's been many questions about maintenance and the future of jscodeshift. There are currently no active maintainers of jscodeshift at Meta. I took over as the 'official' maintainer starting from the 0.12.0 release (April 2021) and have handled all releases since then, however I'm not doing any active development work on the project.

In 2022, I added @ElonVolo as a maintainer. He was maintaining his own fork of jscodeshift called "evcodeshift", and has some great ideas for modernization of jscodeshift.

Today, I'm adding the Codemod team as maintainers. They are experts in codemods, and their expertise combined with @ElonVolo's deep understanding of the jscodeshift codebase will help drive the jscodeshift project forward. They’ll be working on a brand new version of jscodeshift in TypeScript, improving maintainability and fixing many of the existing issues.

I understand that introducing new maintainers can raise concerns. Meta and I will continue to retain control of the repo and npm package, and I will still be the person who publishes new versions.

Please let me know if you have any questions or concerns.

[morgante]

Hi @Daniel15! It's great to see some more maintenance on jscodeshift.

For some context, I'm the founder of Grit and we've been doing a lot of foundational work on code rewriting (including open sourcing a toolkit).

I'd love to understand the decision to partner with Codemod exclusively, and would appreciate a chance to discuss how we might contribute as well.

[Daniel15]

@morgante Codemod are a partner, but anyone is welcome to contribute and we can always add more maintainers and contributors if needed/wanted. If you've got some ideas about ways to improve jscodeshift then I'd recommend chatting to @ElonVolo and @alexbit-codemod. 😃

[morgante]

@morgante Codemod are a partner, but anyone is welcome to contribute and we can always add more maintainers and contributors if needed/wanted. If you've got some ideas about ways to improve jscodeshift then I'd recommend chatting to @ElonVolo and @alexbit-codemod. 😃

How do we become a "partner" too? It feels a bit icky to not have a level playing field for an open source project, especially when we have done extensive original development.

Respectfully, I don't think this is a good look for this project. Giving exclusive partnership rights to a commercial company outside Meta, without any community input beforehand, doesn't feel in the ethos of open source.

[Daniel15]

@morgante jscodeshift has been in need of maintainers for a while. For example, see #482 from February 2022, but it was an issue even before then. ElonVolo was the only individual contributor and Codemod was the only company that reached out about contributing to the project, which is why they're both contributors to the project now. Anyone else could have reached out in exactly the same way any time over the past few years.

It feels a bit icky to not have a level playing field for an open source project,

I'm not sure how it's not a level playing field. You can contribute to jscodeshift in the same way that anyone else can. If you want to become a contributor, then send some pull requests or make some discussion posts about what you think the future of jscodeshift should be.

we have done extensive original development

Development on jscodeshift, or in general? If it's development on jscodeshift, feel free to submit the development work as pull requests. If it's development on other tools, then I'm not sure how that's relevant in this repo.

Giving exclusive partnership rights to a commercial company outside Meta,

I think you may be taking the word "partnership" too seriously. It's not a signed contract or anything like that. Codemod has just agreed to help with jscodeshift's development and maintenance, since it's a tool that they use themselves.

without any community input beforehand

The community input has been that people want to see jscodeshift receive more maintenance and development. They don't particularly care who does that work, just that it gets done.

[morgante]

ElonVolo was the only individual contributor and Codemod was the only company that reached out about contributing to the project, which is why they're both contributors to the project now.

I've reached out to @ElonVolo to offer our support, and have previously tried to contact people at Meta.

I'm not sure how it's not a level playing field. You can contribute to jscodeshift in the same way that anyone else can.

Not really, as Codemod is marked as the "official" maintainers and you explicitly endorse their platform.

This has a significant chilling effect on our willingness and ability to contribute. Codemod.com is our direct competitor and you've effectively handed them control of the project but I don't see any commits in the history from @alexbit-codemod or his team.

Can you explain why the bar for us is "put a bunch of work in to contribute code, and hope our direct competitor will accept that without hurting us" while they get maintainer privileges without contributing a single line of code?

For the record, this is exactly why major open source projects are careful about not privileging a single vendor. If you are going to partner with companies, there should be a process where all can be given consideration. As far as I can tell, @alexbit-codemod was given this privilege without any community discussion or any way for others to contribute.

Development on jscodeshift, or in general? If it's development on jscodeshift, feel free to submit the development work as pull requests. If it's development on other tools, then I'm not sure how that's relevant in this repo.

We originally did development on jscodeshift/codemods, but shifted for many of the same reasons that were identified here - it didn't seem like any of the codemod "stack" was being maintained, and all other outside contributions have lingered in limbo.

I also think our track record of open source work beyond jscodeshift is relevant here. We do extensive original open source development ourselves, including contributions to many other repos, instead of just wrapping our brand around existing open source projects. Perhaps it was my mistake to focus on this instead of fostering closed-door partnerships.

[Daniel15]

effectively handed them control of the project

Meta still has control of the project. Nobody else has full admin repo access (in fact I don't think I even have that), nor does anyone else have access to publish the jscodeshift package to npm. I'm still reviewing commits before publishing releases.

Can you explain why the bar for us is "put a bunch of work in to contribute code, and hope our direct competitor will accept that without hurting us" while they get maintainer privileges without contributing a single line of code?

The project needed maintainers, and they asked if they could be maintainers. I spoke to their team and it seemed reasonable to me given their focus is codemods. Now the project has maintainers. That's it. Anyone else (whether a person or a company) could have asked the same thing any time in the last few years and they would have been treated exactly the same way.

ElonVolo and Alex at Codemod had some ideas about the future of jscodeshift - nobody else has really thought about it in that much detail. Like I said, you're also welcome to post a discussion about what you think the future of jscodeshift should be.

We originally did development on jscodeshift/codemods, but shifted for many of the same reasons that were #500 (comment) here - it didn't seem like any of the codemod "stack" was being maintained,

In that case, it sounds like you're not interested in contributing, in which case I'm not sure why you're even discussing this.

There's been some thoughts around creating a jscodeshift-specific fork of ast-types and recast, or switching to different libraries if any are available for this purpose. You're also welcome to create your own fork, like Elon did with evcodeshift (and AFAIK most of the changes have been merged back into jscodeshift by now).

[morgante]

Anyone else (whether a person or a company) could have asked the same thing any time in the last few years and they would have been treated exactly the same way.

Great, I'm asking if we can be maintainers too.

In that case, it sounds like you're not interested in contributing, in which case I'm not sure why you're even discussing this.

I'm interested in contributing if we can do so on a level playing field.

We've done a lot of foundational work on the parsing/rewrite side and are interested in porting some of that to run with a jscodeshift-compatible API.

[trivikr]

Hi folks, this is Trivikram - maintainer of AWS SDK for JavaScript and author of https://github.com/aws/aws-sdk-js-codemod which uses jscodeshift. I've been contributing to jscodeshift on and off for the past two years, and I'm glad that's it's getting updates in the recent past. Opinions below are my own and not the views of my employer.

I went through the conversation, and I think a Technical Steering Committee like solution would be good for jscodeshift similar to how it's done by Node.js in https://github.com/nodejs/TSC. Two organizations are already listed in the comments above, and Daniel/Elon have been actively maintaining jscodeshift in the recent past.

[Daniel15]

I think a Technical Steering Committee like solution would be good for jscodeshift similar to how it's done by Node.js in nodejs/TSC

jscodeshift is a significantly smaller project than Node.js though. I'm not familiar with how Node.js handles things, and I guess I don't completely understand the value that a TSC would provide, as it seems very heavyweight. jscodeshift is really a community project and everyone is welcome to contribute ideas, code, documentation, etc.

I'm not sure it's something we need at this point in time, but if you'd like to, can you please create a separate discussion post for this? It looks like the "Discussions" feature isn't enabled in this repo, and I don't have the right permissions to enable it. I just filled out a form to request it be enabled. Discussions can happen in there once it's enabled 😄

I'm going to close this issue so that further discussions can happen in separate threads rather than in the comments of an announcement issue.

Thanks!

[Daniel15]

Discussions have been enabled. https://github.com/facebook/jscodeshift/discussions

[ElonVolo]

At this point a jscodeshift technical steering committee is kind of like trying to start a Homeowners Association in a neighborhood where you still don't have indoor plumbing, electricity, or paved roads.

From what I understand of jscodeshift history, the whole project seems to have been originally slap-dashed together under-the-radar at Facebook in whatever free time Facebook employees had available. While this approach might have made the software possible in the first place, it lead to a lot of technical debt and a Big Ball of Mud architecture that has to be remediated.

What I'm trying to avoid is a steering committee that's a hundred steps ahead of what can be added easily to the code. When a TSC is that far ahead it's going to potentially generate a lot of pressure to take on more technical debt to get "quick wins" and keep it up to date with TSC decisions.

[danieldelcore]

I agree, a TSC would be too much overhead for the moment, however, I appreciate the sentiment. Perhaps a more lightweight way of working in a similar vein would help get the project moving again in the short term.

Using Discussions as suggested, for RFC-style proposals would help us collectively contribute to the future architecture in a way that is not biased to any one group's needs. (I made a start here)

I'm trying to avoid is a steering committee that's a hundred steps ahead of what can be added easily to the code.

Agree with you @ElonVolo, there are a lot of quick wins (like the ones you have suggested and integrated into evcodeshift), that could and should just be traditional PRs to the repo. With more maintainers I would expect PRs and releases to flow more regularly. (on that note, integrating Changesets into this repo would eliminate this entire category of problem).

@Daniel15, I'd also be willing to take on maintainer responsibilities, but also just as happy to contribute from the outside. Up to you.