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

241–250 of 412 posts

Re: The tragedy of running an old Node project

#241

Post by gre »

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.

I just today tried reviving an old v12.4 node project and node-gyp is trying to use python2 which I don't even have on my Macbook anymore.

Re: The tragedy of running an old Node project

#242

Post by hombre_fatal »

OP was trying to install an old dep tree of gatsby on a different node target. These kinds of massive libraries break all the time. Look how big its dependency tree is: https://npmgraph.js.org/?q=gatsby

Fortunately this mindset has been changing in the node ecosystem with projects like https://hono.dev/ (koa/express successor) and https://github.com/porsager/postgres having zero deps.

Re: The tragedy of running an old Node project

#243

Post by addicted »

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.

If node saved you 8 seconds per working day over those 4 years, you’d still be ahead spending 2 more hours on that node project every 4 years.

Re: The tragedy of running an old Node project

#244

Post by brokencube »

dmuth wrote: post #220

This is one reason why whenever I build a new project, I build it inside of a Docker container. That way, the project has just the dependencies it needs, and I know I can rebuild it at some point in the future and will be unlikely to run into problems when I do.

My first step now when trying to resurrect old projects is to create a Docker container for it - that way I can install any old versions of anything (like node or PHP) I need without having to worry about it polluting anything else on the system.

Re: The tragedy of running an old Node project

#245

Post by liontwist »

regularfry wrote: post #239
liontwist wrote: post #235

Earlier quoted context omitted.

Quicklisp is merely a registry for getting libraries, not shipping code. Download what you want and use asdf.

Yes, that's what makes it immature. There doesn't seem to be anything in the ecosystem to handle version resolution. Qlot is a start towards that in that you can at least specify alternatives to get yourself out of a hole, but you still ended up in the hole in the first place.

I think it’s a good thing. I don’t want npm for Common Lisp.

Re: The tragedy of running an old Node project

#246

Post by Cu3PO42 »

dmuth wrote: post #220

This is one reason why whenever I build a new project, I build it inside of a Docker container. That way, the project has just the dependencies it needs, and I know I can rebuild it at some point in the future and will be unlikely to run into problems when I do.

This works as long as your Dockerfile is reasonably reproducible and does its best to lock dependencies. However, this approach has failed me a couple of times in the past. For example, I rebuilt a container some weeks later, in the meantime a new version of clang had been released that just so happened to break my build due to a bug.

I personally use Nix these days, but the complexity is too high for me to recommend it to everyone for every software project.

Re: The tragedy of running an old Node project

#247

Post by brunoarueira »

I think many issues goes with bad version or, in some edge cases, not vendor dependencies. I'd good and bad experientes on multiple programming languages, some bad examples:

- bump patch or minor version from a react package but the maintainer rewrote the entire project breaking a lot of things, following semver it's bad to expect things don't break like that for such version; - another example, the ruby gem is removed/yanked from rubygems.org and you'd to find a fork available

On the end, we need to ensure the good practices from software engineering about tests and good release management, the last btw is decades old

Re: The tragedy of running an old Node project

#248

Post by gr4vityWall »

I recently migrated a project to Node.js 8 (!) to Node.js 14 (hopefully just the beginning), and I can relate to this post.

In the JS ecosystem, I'm aware that Meteor is one major framework that takes backwards-compatibility seriously. Updating a project on an ancient version to a less-ancient version usually is not too hard. They try to keep APIs the same and introduce compatibility packages where possible.

Meteor 2.16 to Meteor 3 introduced major breaking changes due to an underlying technical issue that had no workaround. They had to refactor the whole project from using Fibers-based concurrency to typical async/await.

node-gyp in general has also been a source of issues in the past for me as well.

More recently, ESLint changed their configuration file format and all existing tutorials suddenly became outdated.

I firmly believe the ecosystem does not have to be like this, and we would save a lot of man-hours by being more committed to API stability where possible.

Re: The tragedy of running an old Node project

#249

Post by ericmcer »

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

Exactly, you would have to compare it to other package managers to make it fair.

Npm at this point is probably the most used and most worked on package manager in history. If it is still one of the worst ones that is actually kind of interesting philosophically.

Re: The tragedy of running an old Node project

#250

Post by marcosdumay »

abdisalan wrote: post #5
Klonoar wrote: post #3

You know, I ran into something similar recently with a static site engine (Zola). Was moving to a new host and figured I'd just copy and run the binary, only to have it fail due to linking OpenSSL. I had customized the internals years ago and stupidly never committed it anywhere, and attempting to build it fresh ran into issues with yanked crates. Since it's just a binary though, I wound up grabbing the OpenSSL from…

Hold on, you had to do binary surgery using an OpenSSL version from an old box you had? I salute the dedication.

Looks to me he just copied a shared library and changed the search path.

Also, if it was statically linked, he wouldn't have that one problem. (Could have others, but not that one.)

Post reply on HN