Ask
254
@bobbin_bind ·

picked it back up after 8 months and nothing installs - upgrade everything, pin everything, or rewrite

Side project, last commit in November. Went to run it this weekend and the install fails outright. The Node version the project expects is past its support window, two dependencies have deprecation warnings that are now errors, the lockfile references a package version that seems to have been pulled, and the framework has had a major release in the gap.

I had four hours. I spent all four not running the app.

Is the right move to bulldoze - upgrade the runtime and every major and eat a day of breakage - or to reconstruct the old environment exactly and get it running first? Or is 'a rewrite is faster' actually true here?

10 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @chainwax_chloe · 3w ago · 3 replies

    Get it running first, on the old versions, in a container. You need a green baseline before you change anything, or you'll be debugging your upgrade and your rot simultaneously and you won't be able to tell which broke what.

    Pin the old runtime in a Dockerfile, get the app up, commit that, then upgrade one major at a time with a working state to fall back to. It feels slower and it isn't. The four hours you just spent are exactly what happens when you skip the baseline.

    121
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @scopecreep_sam · 3w ago

      And commit the working container config as its own commit before touching a single dependency. Future you needs a point to bisect from.

      54
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @printbed_gremlin · 4w ago

      This is also the argument for committing the lockfile and a tool-versions file from day one. Costs nothing at the time and it's the only thing that makes an eight month gap survivable.

      26
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @parquet_pile · 4w ago · 2 replies

    Concrete framing on the runtime part: Node majors have a published lifecycle, and the even-numbered ones get roughly three years in total, with active support only for the first year or so. If your project is sitting on an odd version or one that's dropped off the list, you're not choosing between upgrading and not upgrading, you're choosing between upgrading now and upgrading later with more drift on top.

    Target the current LTS. Jumping two Node majors is usually far less painful than jumping one major of a web framework, so do the runtime first.

    87
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @two_vcpu_club · 4w ago

      Agreed on order. Runtime, then build tooling, then framework, then your own code. Doing it in any other order is where the whole weekend goes.

      33
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @integral_ines · 4w ago · 2 replies

    The rewrite question deserves a real answer rather than the reflex 'never rewrite'. Ask what fraction of the code is your logic versus glue. If a side project is 80% framework wiring and 20% the thing that makes it yours, scaffolding fresh and porting the 20% genuinely can be faster than an upgrade path through three majors. I've done it, it took a weekend, and the old repo stayed as reference.

    If it's a real product with users and data, absolutely not. Upgrade incrementally. The difference is whether anyone is depending on it right now.

    64
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @compost_turner · 3w ago

      The honest test is whether you can describe what the 20% does from memory. If you can't, you don't understand it well enough to port it and you'll just rebuild the bugs.

      28
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @darning_dot · 4w ago

    Pulled package versions are often still resolvable from your local cache or a mirror. Check that before assuming you're forced into an upgrade.

    41
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @committee_kim · 4w ago · 2 replies

    Came back to a project after about a year and what unblocked me was much dumber than any of this: I wrote a single file at the top of the repo with the exact commands to get it running and which versions of what. Took twenty minutes while it was fresh, right after I fixed it. When I came back three months later I lost zero time.

    The reason an eight month gap hurts isn't really the dependencies, it's that you've also forgotten how your own thing works. The dependency rot just makes that visible.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @repot_ren · 4w ago

      Worth adding a line about why you stopped, too. Half the time it's a decision you were avoiding rather than a bug.

      11
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report