HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
meta
jscodeshift
JavaScript2016–2024
meta / jscodeshift

jscodeshift

A JavaScript codemod toolkit.

Web Development
Explore on GitHubRead Hacker News discussions
15Distinct people
17Mentions
0Explicit recommenders
10KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A JavaScript codemod toolkit.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2016-05-18 14:31:58 UTC to 2024-06-16 03:13:38 UTC.

012342016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC413
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

17 sources
striking·Jun 16, 2024
It's more common than you think! Tools like https://github.com/facebook/jscodeshift, https://ts-morph.com/, and https://ast-grep.github.io/ are the ones I'm more familiar with (since my day-to-day is TypeScript). When I led the conversion of a decently-sized codebase from Flow-typed JS to TypeScript, I ensured that a code formatting tool that we were already using on pre-commit and CI called `prettier` was executed after each step. We took a git snapshot of each step of our automated conversion pipeline, and the diff was much clearer with `prettier` in place at each of those steps. We've since used codemods frequently to make huge changes to the codebase in an automatic, reproducible, iterable way. They're very comfortable, very fun, and (thanks to the use of a formatter on all code) rarely produce incomprehensible diffs.
In Reformatting 100k Files at Google in 2011
ecuaflo·Feb 22, 2023
Those are important but tough problems! 1. I feel like codemods and a setup shell prompt are the best solution to this, but this looks different for each language (eg, in JS there is https://github.com/facebook/jscodeshift). I could make UI around that for listers to provide parts of the app that should replaced and buyers to provide values for it, but it could be quite a rabbit hole. This is actually why I show the README for the repos, so users can see if the setup steps are comprehensive before buying (for paid ones). 2. I agree atomic commits can help someone navigate a new codebase. In the same spirit as my response to #1, I don't feel confident I could enforce this, but I could surface the commits on the starter repo page so potential buyers could see if the author laid things out well. Thanks for the ideas!
In Show HN: Starter.place – Gumroad for Starter Repos
JakeVacovec·Sep 6, 2022Submission

Launch HN: FlyCode (YC S22) – Let product teams edit web apps without coding

Hi HN community, we are Jake, Tzachi and Etai, co-founders of FlyCode (https://www.flycode.com/). FlyCode makes it easy for product, UX, and marketing teams to edit web apps without coding, so they don’t have to wait on (or consume) developer time, and can iterate, test, and release faster. See a quick example here: https://www.youtube.com/watch?v=jDL5oa2nEHo. Non-technical teams frequently need to edit the copy (text), images, and links that appear in a web app. How to manage these has long been a pain on software projects. You can keep them separate from the code, in some form that non-programmers can edit, but this adds a lot of complexity and is usually brittle, as it can bypass the regular development workflows (CI, staging envs, deploy previews). It’s simpler to keep them in the code, but then only programmers can easily edit them.
Read the rest
Everyone else has to wait to get their changes in, plus the devs have to do a lot of edits that aren’t their main work. This slows projects down and is expensive. It also means that product/marketing/UX teams can’t do things that require rapid iteration, such as sophisticated forms of A/B or usability testing. This limits their work and ultimately is bad for both quality and revenue. There have been many approaches to solving this dilemma, including custom built admin tools that are limited in functionality and require maintenance, offloading to CMS that require heavy integration, are normally used for simple static apps, and bind your stack to their SDKs. Or wasting a developer’s time to do it for you… We took a new approach by automatically analyzing a codebase’s structure, similar to a compiler. This allows us to automatically prepare a project-specific version of our platform which product/UX/marketing teams can easily use to edit their text and images. We programmatically turn those edits into code changes. Our GitHub bot then takes these code changes and creates a pull request just like a developer would—but without the latency (and boredom!). Developers retain codebase ownership, while non-developers become individual contributors to the dev process, just like others. We use well-established practices for parsing and editing source code (like https://github.com/facebook/jscodeshift), covering most of the major technologies used for building web apps (React, Angular, Vue, and Ruby on Rails included). Once our software has parsed your codebase, it generates an editing portal for your app that teams can easily use to find, manage, and edit product copy, images, and links, and then auto-generate PRs. You can edit product copy regardless of whether it is in resource files or hardcoded (fun fact: some of the largest and fastest-growing tech companies have most of their strings hardcoded!), and you can replace and upload new images and icons to your product. The integration with GitHub (https://www.flycode.com/developers) took us a long time to get right. There’s not a lot of documentation around integrating GitHub to platforms, and things like connecting an org or connection requests turned out to be non-trivial. We're proud of the result because unlike with other tools, you don’t have to do any significant integration work. Our GitHub app finds texts and images in the source code and sends them to our platform (you have full control of what and where we scan). Once a user requests a change it updates the texts and the images in the codebase and creates a pull request. We did a Show HN earlier this year: https://news.ycombinator.com/item?id=31166924, which helped us get some serious leads, which was awesome. Since then we’ve moved out of beta, added new content types (images!), launched a new UI and visual editor (EAP), and automated the onboarding of new repos. We have a handful of companies paying for this and spent the last year focusing on making it extremely simple to use. It only takes 3 minutes to connect our GitHub app and configure the system for your team to start editing. It doesn’t require any changes to your code, or any special maintenance. You can get started here: https://app.flycode.com We are hoping to use this launch to get some more feedback from you all! We are far from our vision to be a platform for everything front-end but are working hard every day to improve the user experience and feature requests from our early collaborators (editing links, themes, variables, JSON configuration, defining in-code A/B tests, etc.). We're really happy to show this to you all and thank you for reading about it. For those that sign up, time yourself to check that our “3-minute connect + config” claim isn't just a sales tactic! We look forward to further conversation in the comments.
141 points · Open discussion
MarkSweep·Aug 17, 2022
RE: Program is a model There are some more advanced refactoring tools now available. These tools enable you to write code to detect bad code patterns and even automatically fix them. You can use them to write one-off transformations of code too. Rust has Dylint [1] and C# has Roslyn Analyzers [2]. Facebook has tooling [3] that helps writing CodeMods, enabling authors to generate changes for thousands of files at a time. The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine. Something that keeps track of which tests are flaky and which are broken on master, so you don't have to diagnose spurious build failures. Something that only runs the test that tran
Read the rest
sitively depend on the code you change. Automatic bisecting of errors to the offending commit. [1] https://github.com/trailofbits/dylint [2] https://docs.microsoft.com/visualstudio/code-quality/roslyn-... [3] one example: https://github.com/facebook/jscodeshift
In Programming breakthroughs we need
kevlened·Apr 12, 2022
This is a powerful idea! If I understand Monocle's use case, JS has similar AST parsing and code generation tools that are used broadly. There may be some ideas to learn from that community. JS AST specs: estree [0] and babel's AST [1] Parsers: babel [2], acorn [3], or espree [4] Transformers: babel, recast [5], or jscodeshift [6] Codegen: babel or escodegen [7] [0] https://github.com/estree/estree [1] https://babeljs.io/docs/en/babel-parser#output [2] https://github.com/babel/babel [3] https://github.com/acornjs/acorn [4] https://github.com/eslint/espree [5] https://github.com/benjamn/recast [6] https://github.com/facebook/jscodeshift [7] https://github.com/estools/escodegen
In Show HN: Monocle – bidirectional code generation library
TheAceOfHearts·Jun 21, 2019
Definitely agree that most programmers would benefit from studying these topics. They have broader applications than many realize. You can use tools like jscodeshift [0] to refactor code! I've previously written codemods to migrate away from a bad design decisions. The React team has also used codemods to introduce breaking changes. AST Explorer [1] is the best tool I've found for writing codemods since it gives you nearly instant feedback and allows for a good amount of exploration. [0] https://github.com/facebook/jscodeshift/ [1] https://astexplorer.net/
In A New Bytecode Format for JavaScriptCore
TheAceOfHearts·Feb 16, 2018
I totally agree. I'd love to see more languages supporting bidirectional code transforms. I've used jscodeshift [0] to refactor large JavaScript codebases, and it's absolutely amazing. It's incredibly empowering to write code to update your code. For example: unhappy with your test assertions library? Safely migrate all your tests with a quick script. The React team has a react-codemod [1] repo which has scripts to help you update to newer APIs. That means they can make changes and iterate on improvements without leaving people behind. Quite frankly, I don't see why more tools, libraries, and frameworks wouldn't do the same. [0] https://github.com/facebook/jscodeshift [1] https://github.com/reactjs/react-codemod
In Just what does “code as data” mean anyway? (2014)
TheAceOfHearts·Sep 2, 2017
I'd strongly suggest diving into compilers if you've never studied the subject. Learning a bit on the subject unlocks a ton of incredibly useful skills. That knowledge helps you implement stuff like autocomplete, linters, syntax highlighting, etc. The Super Tiny Compiler [0] is a very gentle introduction to the subject. It's great because it helps you quickly develop an initial mental model. To give an everyday usage example: I've used jscodeshift [1] many times to safely refactor large amounts of code. In one case, I quickly migrated a project's test assertion library to an alternative which the team agreed was superior. This tool is also typically used by the react team in order to provide a smooth migration path whenever they make changes to the public API. [0] https://github.com/thejameskyle/the-super-tiny-compiler [1] https://github.
Read the rest
com/facebook/jscodeshift
In My first fifteen compilers
stringham·Aug 24, 2017
I find the idea of https://github.com/facebook/jscodeshift to be really useful. I've started writing small scripts using the TypeScript parser as a library to make meaningful improvements in our codebase. Since JavaScript is valid TypeScript syntax the scripts work on both. For example, I wrote a small script to change var to let or const when possible. It uses the AST to check scoping rules and to check if a variable is ever reassigned. Writing scripts like this is way more effective than doing it by hand.
In Codemod – A library to assist with large-scale codebase refactoring
hzoo·Feb 13, 2017
For JavaScript we have https://github.com/estree/estree as our JS AST spec for parsers like esprima, acorn, babylon (under a config flag), etc. JSCS (https://github.com/jscs-dev/node-jscs) (now merged with ESLint) started a CST project as well https://github.com/cst/cst to help deal with autoformatting by adding whitespace type nodes. Currently the community has a lot of interest in https://github.com/jlongster/prettier which just simply reprints the file from scratch in a consistent way (posted in https://news.ycombinator.com/item?id=13365470). We also have https://github.com/benjamn/recast to help source to source transformations and https://github.com/facebook/jscodeshift.
In From AST to Lossless Syntax Tree
throwanem·Jun 23, 2016
I think everybody is; it looks like whatever CMS they're using eats newlines out of content pasted into <pre>s, because there aren't any in the source. Maybe it's a cavil, but I'm not overjoyed at the thought of doing global search and destroy on my codebases with a tool I heard about on a website that messes up something that basic. On the other hand, apparently jscodeshift itself comes from Facebook [1], and they tend to do good work (on a technical level, at least); perhaps it'd be worthwhile to change the HN link to point to that repo, not least because the code samples aren't munged to unintelligibility there. [1] https://github.com/facebook/jscodeshift
In Write Code to Rewrite Your Code: jscodeshift

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.