Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

31–40 of 412 posts

Re: The tragedy of running an old Node project

#31

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

> But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native.

Because the native written stuff breaks all the darn time and it creates cross-plat nightmares.

My stress levels are inversely proportional to how many native packages I have to try to get building within a project, be that project in Python, Java, or JS.

JS+Node runs on everything. Prepackaged C++ libraries always seem to be missing at least one target platform that I need!

Re: The tragedy of running an old Node project

#32
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

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

Re: The tragedy of running an old Node project

#33
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

> Two hours of work after 4 years sounds ... perfectly acceptable?

Does it, though? Node wasn't exactly new 4 years ago, and plenty of other languages would offer a better experience for even older code -- Java, C, C++ to name a few.

Re: The tragedy of running an old Node project

#34
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

You’re absolutely right. My rational brain agrees and chalks it up to poor project management. However… emotions run high when you have zero idea why something isn’t working and the process of elimination is pretty taxing. So the point for me is venting / maybe someone will read this and remember to write their node version down!

Re: The tragedy of running an old Node project

#36
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

Also, Gatsby has dependencies that aren’t even Node. I have had it break too.

Re: The tragedy of running an old Node project

#39
I would heavily recommend to avoid NodeJS packages that depend on node-gyp. Node-gyp powered dependencies are very seldomly worth the hassle.

If you must depend on node-gyp, perhaps use dev containers so at least every developer in your team can work most of the time.

Re: The tragedy of running an old Node project

#40
post #27

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…

> For those reading this who don't know much about node

I would prefer to remain blissfully ignorant, thank you!

Post reply on HN