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

21–30 of 412 posts

Re: The tragedy of running an old Node project

#21

Post by 91bananas »

kaptainscarlet wrote: post #13
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…

That is nothing..Try building your Android project after leaving it idle for a week. Or better yet, try building you react native project you left for 2 days.

OMG I feel this in my soul. Try looking at one of the gradle files wrong in a kotlin multiplatform app with shared ui.

Re: The tragedy of running an old Node project

#22

Post by ramesh31 »

binarymax wrote: post #17

I always try to remember to put the node version in my package.json - but I do agree that the dependency chain on node-gyp has been a blight on node packages for awhile. Really wonder how that wart became such a critical tool used by so many packages.

>Really wonder how that wart became such a critical tool used by so many packages.

The original dream for Node was that it would simply be a glue wrapper around libuv that allowed for easy packaging/sharing of modules written in C++. But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native. Ryan Dahl stated this was indeed his biggest mistake/regret with Node, thus we have Deno now.

Re: The tragedy of running an old Node project

#23

Post by mvkel »

> 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

Re: The tragedy of running an old Node project

#25

Post by beardyw »

I'm pretty sanguine about languages and frameworks, but I draw the line at node. I have seen so many horrors visited by dependencies, often to do just one thing where 2 or 3 lines of code would do the job anyway.

When I was managing teams, whatever the language, I would ban any new dependencies which I didn't personally agree with. A lack of control just creates a nightmare.

Re: The tragedy of running an old Node project

#26

Post by everythingishax »

This is literally every "hot new thing" since 2000.

It is systemic. Part of it is due to too many people creating systems on the fly with too little forethought, but also because there aren't enough "really smart people" working on long term solutions. Just hacks, done by hacks. What did you expect when the people writing the systems don't have long term experience?

Re: The tragedy of running an old Node project

#27

Post by com2kid »

binarymax wrote: post #17

I always try to remember to put the node version in my package.json - but I do agree that the dependency chain on node-gyp has been a blight on node packages for awhile. Really wonder how that wart became such a critical tool used by so many packages.

node-gyp is a huge source of these issues for Node projects, especially older ones.

For those reading this who don't know much about node - node-gyp is how you pull in native code libraries to Node projects, typically for performance reasons. You get the same sorts of build issues with it that you can get whenever you start having binary, or source, dependencies, and you need the entire toolchain to be "Just Right(tm)".

I run into this issue with older Node projects on ARM Mac machines (Still!), but I run into similar issues with Python projects as well. Heck some days I still find older versions of native libraries that don't have working ARM builds for MacOS!

Node used to have a lot more native modules, in newer code you typically don't see as much of that, and accordingly this is much less of an issue now days.

> I always try to remember to put the node version in my package.json

This 100x over!

Re: The tragedy of running an old Node project

#28

Post by toast0 »

abdisalan wrote: post #18
rootnod3 wrote: post #10

Earlier quoted context omitted.

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.

I’m curious, how do you measure the pulse of a project that old? Do people still talk about it? Or that not even necessary — use it until it breaks and otherwise don’t think about it?

If it has an issue tracker, you can look in there for things that look like real issues and are unaddressed.

If there's no issue tracker, you can YOLO and try it and see if it works, or you can look around at the code and see if it looks reasonable.

Even if there are unaddressed issues, you can always use it and fix it when it breaks. If it's reasonable enough, it's a good start anyway. And at least my assumption with open source is I'm going to be fixing it when it breaks, so lack of a pulse is better than churn.

Re: The tragedy of running an old Node project

#29

Post by tpm »

vessenes wrote: post #6

This 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 T…

Yeah I'd expect 20yo Perl5 stuff to work without issues.

A few weeks ago I was experimenting with a sound generation dsl/runtime called Csound and even most 30yo sources were working as long as they didn't use some obsolete UI.

Re: The tragedy of running an old Node project

#30

Post by skybrian »

vessenes wrote: post #6

This 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 T…

Go’s minimum version selection is the way and I don’t understand why other ecosystems haven’t adopted it. You’re be able to compile an old project with all the library dependencies it had at the time it was released. It might have security issues, but at least you start with a version that works and then can go about upgrading it.

It also helps that if some library dependency generated Go code using a tool, the Go source code is checked in and you don’t have to run their tool.

Post reply on HN