←back to thread

The tragedy of running an old Node project

(abdisalan.com)
272 points abdisalan | 9 comments | 18 Nov 24 18:24 UTC | HN request time: 0.001s | source | bottom
Show context
mvkel ◴[18 Nov 24 19:03 UTC] No.42175730[source]▶
> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

replies(21): >>42175799 #>>42175818 #>>42175826 #>>42175846 #>>42176217 #>>42176305 #>>42176788 #>>42176958 #>>42181497 #>>42182299 #>>42182564 #>>42182778 #>>42183020 #>>42183093 #>>42183501 #>>42183725 #>>42184814 #>>42192770 #>>42193606 #>>42194518 #>>42211558 #
ivan_gammel ◴[19 Nov 24 13:19 UTC] No.42183093[source]▶
I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me.
replies(5): >>42183272 #>>42183987 #>>42184062 #>>42184422 #>>42187870 #
1. demosthanos ◴[19 Nov 24 13:38 UTC] No.42183272[source]▶
Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later.
replies(3): >>42183488 #>>42185664 #>>42188426 #
2. ivan_gammel ◴[19 Nov 24 13:59 UTC] No.42183488[source]▶
Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
replies(2): >>42183533 #>>42183997 #
3. demosthanos ◴[19 Nov 24 14:03 UTC] No.42183533[source]▶
Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability.

There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point.

4. lowboy ◴[19 Nov 24 14:48 UTC] No.42183997[source]▶
Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.
replies(1): >>42184056 #
5. cesarb ◴[19 Nov 24 14:54 UTC] No.42184056{3}[source]▶
> Well, the article is about npm, a package manager for node.

And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.

replies(2): >>42184253 #>>42185188 #
6. ivan_gammel ◴[19 Nov 24 15:12 UTC] No.42184253{4}[source]▶
Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes.

It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem.

7. lowboy ◴[19 Nov 24 16:24 UTC] No.42185188{4}[source]▶
Pinning to exact versions has been supported in npm for most, if not all of its life.

That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable).

8. trinix912 ◴[19 Nov 24 17:06 UTC] No.42185664[source]▶
Might be an unpopular opinion but I like it that way. It means that I can pull an old Gradle version and the build should succeed. Unlike maven where I’ve been bitten by plugin xml syntax changes and such.
9. cypressious ◴[19 Nov 24 21:44 UTC] No.42188426[source]▶
If you use the the Gradle wrapper, it will use the correct version and download it if necessary. If I'm not mistaken, that's the recommended approach.