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

271–280 of 412 posts

Re: The tragedy of running an old Node project

#271

Post by lexlambda »

RadiozRadioz wrote: post #212

I call this phenomenon "node rot". Judging by the comments here, it seems like a universal experience. My favorite is the way that Python projects rot. Not only does Python's setuptools give you all the fun that node-gyp does, the common practice of versioning packages with packagename>=1.25.5 means you're almost guaranteed breakages as pip installs newer versions of packages than what the project was built with.

And project specifying "requires python 3.X+" instead of Version X to Y is also a major culprit I often encounter.

Most of the times it will not work with the newest shiny python, which I only notice after already installing it and then having searched search the Github issues.

Re: The tragedy of running an old Node project

#273

Post by cle »

the_mitsuhiko wrote: post #223
hathawsh wrote: post #45

Earlier quoted context omitted.

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 automatic…

Will uv even be around in 4+ years? No idea.

Re: The tragedy of running an old Node project

#275

Post by bastawhiz »

All of the problems here ultimately came down to packages that used the native Node API. You don't need python or deal with C++ to run JavaScript.

Node is an active project. If you build against the native API and don't pin your version to avoid breaking changes between versions, this is what happens. In my experience, JS very rarely breaks between major Node versions, but almost every native package requires a new major update.

This isn't a Node specific problem. Go ahead and upgrade your Go or Python version.

Re: The tragedy of running an old Node project

#276

Post by dilap »

mperham wrote: post #228
KronisLV wrote: post #217

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

Plus even if you were using lots of deps, the Go code would almost certainly keep working, thanks to minimal version selection and the Go module mirror. (And of course for maximum reliability, could even easily vendor deps with "go mod vendor".)

Re: The tragedy of running an old Node project

#277

Post by fbn79 »

cies wrote: post #149
fbn79 wrote: post #136

Earlier quoted context omitted.

I would love the author to test and old java/maven project. Node is a paradise compared to that stack.

The only problems I've run into are related to certain package repos that went offline. So you have to track down suitable versions of certain packages on other repos. OTOH with Node I always find myself in dependency hell with dealing with old projects.

In my experience this only happen if the project does not have a lock file and does not specify a node version (two good practice that must be followed).

Re: The tragedy of running an old Node project

#278

Post by fbn79 »

avtolik wrote: post #140
fbn79 wrote: post #136

Earlier quoted context omitted.

I would love the author to test and old java/maven project. Node is a paradise compared to that stack.

Why do you think so? I have 10+ years old Java/Maven projects that build and run fine.

Maybe you are fortunate or I'm not because in projects I have experienced missing o changed maven repository urls and changed deps packages names or url. And was an hell to fix.

Re: The tragedy of running an old Node project

#279

Post by trinix912 »

andai wrote: post #226
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 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.)

JavaFX? I’ve been there too, had to install it with maven and waste a few hours getting the maven xml just right for it to bundle the entire thing into a runnable jar (one that doesn’t require shipping extra files). Not the most convenient, but I get that they wanted to split it off the JDK release cycle.

Re: The tragedy of running an old Node project

#280

Post by trinix912 »

demosthanos wrote: post #189
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.

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.

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.
Post reply on HN