Old codebase, outdated tool chain - how to limit the blast?
I have a 5-6 year-old enterprisey React codebase at work with a bunch of dependencies that for the most part haven't been upgraded since the day they were first installed. Most of the build chain is two+ major versions behind current: webpack 3, babel (& all loaders/plugins) v6, from before the monorepo reorg, Jest v23, and Flow 🤦 version 0.37. For those who haven't been keeping up with Flow (and who has?) the current version is 0.195.0. It's so old that the flow-language-server in vs code won't start, and the Stripe flow-to-typescipt-codemod works only partially and leaves several thousand compiler errors that it can't address.
Oh, and it's also an ejected create-react-app codebase with a lot of custom build scripts and a really bespoke end-to-end testing setup that I don't pretend to understand.
Anyone who understood this codebase has long since moved on. Right now I'm as expert as anyone else here, and I have the team's blessing to take the reins and upgrade this all to a modern stack. But as I experiment with it, it's a pile of pickup sticks, because anything I pull on seems to require me to upgrade everything else. Target state is Typescript replacing Flow, and either Vite and Vitest replacing the rest of the toolchain— or if that's impossible, at least modern versions of Webpack and Jest.
Question for the channel, as per title: is there any way to avoid a big rewrite that takes a month and breaks a bunch of things I don't know about? Anybody have experience with something similar?
GitHub
GitHub - stripe-archive/flow-to-typescript-codemod: Codemod Stripe ...
Codemod Stripe used to migrate 6.5m+ lines of code from Flow to TypeScript - GitHub - stripe-archive/flow-to-typescript-codemod: Codemod Stripe used to migrate 6.5m+ lines of code from Flow to Type...
11 Replies
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
I'd probably just rewrite it and save the headache.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
Highly depending on how much money this current thing is making for the company, if it isn't profitable now, chances are it won't be profitable after.
if you want to be working in a clean react codebase with good tooling a month from now, my advice would be to send out some CVs
ive been in a similar situation before minus flow
my experience was the same, so many pieces are connected that you get to a point where you cant really see if it works or not before you're done porting the entire thing
sorry i don't really have much good advice
Thanks for the suggestions all. Rewrite (of the build scripts, that is, not the whole app) may truly be the only option, but I can't call it "saving the headache". @lee do you have experience with what you outlined? The way I read it, in the middle of the port I would have two React apps, each with part of the functionality, which wouldn't really give me a way to deploy my changes midway. Might as well be a full rewrite.
It's not a money-making tool, but it's very valuable. I thought by saying it was 5-6 years old I was implying that the company has kept using it for that long. We wouldn't have done that if it didn't do a useful job
I work on a similar project, with the difference being it's written in Javascript. There are some requirements to change the authentication and since it's all mangled up some parts need to be rewrited. My first step was to get the hang of the overall structure of the code, add todos for very messed up things and add type annotations with JSDoc.
Starting with low hanging fruits and seperating stuff to be able to later switch out some parts seems the way to go. I would refrain from a rewrite, it's probably not a fruitful endeavor for a complex application.
And I would not migrate from one library to another if there is no very big value to gain from doing so.
For example migrating away from jest might not be the best idea. It's pretty stable at this point and it works.
I like my tests to run fast.
Yeah who doesn't but that's not a good enough reason if it does not cause a huge problem.
my 2022 was wasted on something similar
project is in a pretty OK-ish place now, but it was not woth the time and effort to do it, would have made so much more sense to just rewrite
from scratch, but hey, it is what it is
this is one of those cases, when I think it makes a lot of sense to start writing lots of E2E tests
it makes all the refactorings a whole lot easier
think of creating a mold via the E2E tests, and then pour the new app into it
so my strategy would be to
1) replace the bespoke E2E test setup with something modern, add bunch of tests to cover all the critical product stuff and edge cases
2) replace build tools --> move to vite
3) establish a new feature based project structure (something like bulletproof react https://github.com/alan2207/bulletproof-react )
4) rewrite stuff route by route / feature by feature