Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

Post reply on HN
Print view View original

221–230 of 412 posts

Re: The tragedy of running an old Node project

#221

Post by lowboy »

ivan_gammel wrote: post #196
demosthanos wrote: post #189

Earlier quoted context omitted.

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.

Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.

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.

Re: The tragedy of running an old Node project

#222

Post by pornel »

vulcan01 wrote: post #187
mst wrote: post #135

Earlier quoted context omitted.

Never underestimate the potential of past-you to have accidentally missed a tiny but essential step in a way that won't have made a noticeable difference at the time, yeah.

This is why Nix (with flakes), in a git repository, will refuse to use a lockfile that isn't being tracked by git.

Nix also breaks if you try to update it, and you'll eventually have to update for security issues.

I'm stuck with a defunct Nix project I can't update, because crane and fenix flakes made breaking changes, and nix is giving me incomprehensible errors. I've spent enough time googling the errors that I'd be quicker to start over with a nix-less VM.

Re: The tragedy of running an old Node project

#223

Post by the_mitsuhiko »

hathawsh wrote: post #45
mattgreenrocks wrote: post #32

Earlier quoted context omitted.

Other ecosystems usually do not have problems to the extent the author had.

I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated vers…

> I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue.

The same problem in Python is much easier now because you can ask the uv resolver to limit itself to some earlier point in time.

You can do `uv pip install --editable . --exclude-newer=2022-01-01` and you will end up with a resolution from two years ago. Since uv can also install older python versions automatically you can easily bisect you to a newer point.

Re: The tragedy of running an old Node project

#225

Post by cesarb »

lowboy wrote: post #221
ivan_gammel wrote: post #196

Earlier quoted context omitted.

Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.

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.

> 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.

Re: The tragedy of running an old Node project

#226

Post by andai »

ivan_gammel wrote: post #179
mvkel wrote: post #23

> 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

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.

I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. Then it turned out the standard built in GUI library I needed was no longer standard or built in. (I also used it ten years ago and it was a much better experience then.)

Re: The tragedy of running an old Node project

#227

Post by andai »

Not defending node here (I had OP's experience almost verbatim), but I had a much worse experience with trying to compile PaulStretch (a C++ project). The dependencies were specified as a bunch of random third party URLs, half of which had gone offline. I ended up giving up after a few hours, and then finding a fork that Just Works.

Re: The tragedy of running an old Node project

#228

Post by mperham »

KronisLV wrote: post #217
ivan_gammel wrote: post #179

Earlier quoted context omitted.

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.

> I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's ano…

> I think the experience of code rot is universal and increases with the amount of dependencies you have.

This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory) and excellent backwards compatibility.

Re: The tragedy of running an old Node project

#229

Post by liontwist »

Ameo wrote: post #75
fourseventy wrote: post #62

Earlier quoted context omitted.

Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...

What ecosystem are you comparing to? Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues. Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.…

I check out C projects which have not been updated in 15 years and run make.

Re: The tragedy of running an old Node project

#230

Post by david_allison »

jonathanlydall wrote: post #164
mvkel wrote: post #23

> 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

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

Not any more. Security vulnerabilities in dependencies now break the build by default.

It's arguable whether this is the correct decision, but it makes things slightly harder than they used to be

Post reply on HN