Small app, maybe 9k lines, worked fine the day I stopped. Today: install fails, the build tool has had two major versions since, and half the packages have advisories.
The rewrite voice is very loud right now. Is it ever right, or is the boring upgrade always the answer?
The rewrite feels clean because you have forgotten the eleven decisions the old code encodes. Every one of them was a bug report or an edge case, and none of them are written down anywhere.
What actually happens: you rebuild 60% quickly, feel great, then reach the same boring part that made you stop seven months ago - the import parser, the billing edge cases, whichever it was - and abandon it again, except now you have two half-projects. Upgrade, ship one small visible thing, then decide with a working app in front of you.
Before touching any of it, read your own README and the last twenty commit messages, then write three lines: what this does, who it was for, why you stopped. Half of abandoned projects do not need a dependency upgrade, they need a decision, and doing the upgrade first is a very effective way of avoiding making it.
Do this before the dependency work rather than after. I spent an entire weekend upgrading a project and realised at about 10pm on the Sunday that I did not actually want it to exist anymore. The upgrade was flawless.
Timings from doing this in April on something similar in size: 40 minutes on the runtime, about 20 minutes of actual application code changes, and the remaining five hours on the bundler config, a test runner that had changed its config format, and CI. Budget a day, not a weekend, and expect the split to be nothing like what you assume.
Jump to Node 20, that is the safe LTS to land on.
20 is out of support now - it reached end of life at the end of April this year, a year after 18 did. The maintenance LTS at the moment is 22, which runs until April 2027, and 24 is the current active line. Land on 22 if you want the least churn, 24 if you would rather not do this again in nine months. Definitely not 20.
Boot it first. Upgrade second. Decide third. Rewrite never.
@pattern_tracer · 4mo ago · 2 replies
First job is getting it running unchanged. Pin the old runtime with a version manager or run it in a container, install with the existing lockfile, and see the thing boot. You need a known-good state before you change anything or you will spend a day unable to tell which of your fourteen changes broke it.
Then upgrade in separate commits, in this order: runtime, then build tooling, then framework, then everything else. The runtime is genuinely easy. The build tooling is where the whole day goes, because config formats change and the error messages are terrible. Budget accordingly and do not start the framework upgrade until the build is green.
Reply
Report
@layer_shift_lu · 4mo ago
And if the lockfile truly will not resolve, delete it and reinstall rather than fighting it - but do that as its own commit with nothing else in it, so the diff shows you exactly which transitive dependencies moved. That diff is also where you find the package that got renamed or abandoned.
Reply
Report