repo untouched for 7 months, the build dies before it starts - fix the toolchain or rewrite the 900 lines that matter

Timebox it and make the decision arithmetic rather than mood. Four hours to a green build. If you are not there, the answer is extract.

The reason that rule works: scaffolding rots and domain logic does not. Your 900 lines of parsing and scoring are the accumulated knowledge of every edge case you hit, and they are worth days. The auth setup, the build config, the deploy scripts, the CI pipeline - all of that is a solved problem you would do differently now anyway, and a current starter template gives you the lot in an afternoon.

When I extracted, the 900 lines went in first with no dependencies other than the standard library where possible, then tests around them from the fixtures, then the new scaffolding around that. The whole thing took eleven hours across two weekends and the result is easier to pick up after a gap, which is the actual problem you are solving.

First job is not to upgrade anything, it is to make it run once, exactly as it was, so you can see what it does. Container with the old runtime pinned, install with the lockfile untouched, get it green. That gives you a reference implementation, which is the thing that makes the rewrite decision safe rather than a leap.

Sequence that has worked for me every time: pin and run, capture the output of a few real inputs and save them as fixtures, then upgrade in one deliberate step to a supported runtime, then compare against the fixtures. Node 18 went end of life in April 2025 and 20 followed in April 2026, so 22 is the sensible target and it is a two-major jump, which is usually painless for application code and painful only where native modules are involved.

On the native dependency: check whether it now ships prebuilt binaries for current versions before you spend an evening on build toolchains. That problem frequently solved itself while you were not looking.

Pin the old runtime, capture fixtures, then extract the 900 lines into a current template. Two weekends is plenty for that and not enough for a full repair.

Going to be the annoying one. The toolchain is not why this stalled.

It sat for seven months before the dependencies rotted. Something else stopped you, and if you spend two weekends on npm and CI you will arrive back at exactly the point you walked away from, except tired and with the sense you already put in the work.

Write down two things before you touch the repo. What was the last thing you were doing when you stopped, honestly, and who is waiting for this. If the answer to the second is nobody, the technical question does not matter yet - go and find one person who wants it, then decide.

Did this exact thing in March and the single most useful hour was writing a RESTART file at the top of the repo before doing anything else.

It has five sections and they are all boring: the exact commands to install and run, what the three moving parts are in two sentences each, what I was in the middle of when I stopped, the three things I know are broken, and one line saying what the next task is. Ninety minutes to write from reading my own code and commits.

The second weekend started with me opening that file and being productive in five minutes instead of two hours. I now write it whenever I know I am about to have a gap, even a two week one.

Worth considering a third option if neither weekend appeals: package it for someone else. That means a running deployment or a container that starts, the 900 lines with a paragraph explaining the domain rules, whatever users or waitlist exists, and an honest note about what is broken.

Assembling that takes about as long as the repair and it forces the same clarity. Half the time I have started that exercise I have talked myself back into finishing the thing, because writing down what is left made it look small. The other half, someone took it and shipped it, which is a better outcome than a repo I open once a year and close again.