The tragedy of running an old Node project
abdisalan.com
The tragedy of running an old Node project
1–10 of 412 posts
Re: The tragedy of running an old Node project
#2I've actually had a node project go bad in a mere 4 months. It must be a new record. That was about 4-5 years ago though.
Hopefully the ecosystem as improved since then, but it was nearly impossible to get going.
Some packages had been changed and the version number overwritten with incompatible packages, and the conflicts were plenty.
Re: The tragedy of running an old Node project
#3You 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 the old box and patching the binary to just point to that instead. Thing runs fine after that.
This is all, of course, still totally stupid - but I did find myself thinking how much worse comparable events in JS have been for me over the years. What would have been easily an entire afternoon ended up taking 15 minutes - and a chunk of that was just double checking commands I'd long forgotten.
Re: The tragedy of running an old Node project
#4I've actually had a node project go bad in a mere 4 months. It must be a new record. That was about 4-5 years ago though. Hopefully the ecosystem as improved since then, but it was nearly impossible to get going. Some packages had been changed and the version number overwritten with incompatible packages, and the conflicts were plenty.
Wow, that’s honestly impressive.
If there was an option to guarantee versions could exist for X amount of years (maybe even months?) then that would greatly help the stability of projects.
Re: The tragedy of running an old Node project
#5You 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.
Re: The tragedy of running an old Node project
#6This will always be an issue for the node community - it’s endemic to the JavaScript shipping / speed culture and the package management philosophy.
Go is much, much better on these terms, although not perfect.
I’d venture a guess that Perl 5 is outstanding here, although it’s been a few years since I tried to run an old Perl project. CPAN was dog slow, but other than that, everything worked first try.
I’d also bet Tcl is nearly perfect on the ‘try this 10 year old repo’ test
Re: The tragedy of running an old Node project
#7I've actually had a node project go bad in a mere 4 months. It must be a new record. That was about 4-5 years ago though. Hopefully the ecosystem as improved since then, but it was nearly impossible to get going. Some packages had been changed and the version number overwritten with incompatible packages, and the conflicts were plenty.
One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa.
It's OK. Not every language ecosystem is so busted that you can reliably expect a project not to work if someone isn't staring at it weekly and building it over and over again just in case. Now, it's always a risk, sure, no language anywhere is immune to the issue [1], but there's plenty of languages where you can encounter things from 5 years ago and your default presumption is that it's probably still working as well now as it did then. It may be wrong, but it's an OK default presumption.
[1]: Well... no language in common use anyhow. There's some really fringe stuff that uses what is basically content-based references for code dependencies, but I'm not aware of anything that I'd call "production quality" that even remotely looks like that, and is immune to someone just plain making an error with the semantic versioning or whatever.
Re: The tragedy of running an old Node project
#8You 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.
How exactly does one do that. Sounds exciting!
Re: The tragedy of running an old Node project
#9You 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…
What’s the issue with yanked crates? It should still build from your lockfile, even if it contains yanked crates.
Re: The tragedy of running an old Node project
#10I've actually had a node project go bad in a mere 4 months. It must be a new record. That was about 4-5 years ago though. Hopefully the ecosystem as improved since then, but it was nearly impossible to get going. Some packages had been changed and the version number overwritten with incompatible packages, and the conflicts were plenty.
One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa. It's OK. Not every language ecosystem is so busted t…
These JS developers would probably shiver at seeing many Common Lisp repos with a last commit like 12 years ago and still working like a charm.