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

281–290 of 412 posts

Re: The tragedy of running an old Node project

#281

Post by icedchai »

liontwist wrote: post #229
Ameo wrote: post #75

Earlier quoted context omitted.

What ecosystem are you comparing to? Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues. Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.…

I check out C projects which have not been updated in 15 years and run make.

I have C code that I wrote in 1995 that still builds. There are many warnings, however.

Re: The tragedy of running an old Node project

#282

Post by trinix912 »

a1o wrote: post #268
neonsunset wrote: post #205

Earlier quoted context omitted.

This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can down…

Note Microsoft still removes downloads of previous versions of Visual Studio that aren't the latest - now you can only download VS2022 unless you have some mysterious paid account that has access to those - I don't have in either my personal or my corporate so I don't know the details

This is true and is a pain if you’re stuck on something like Windows 7/8.1 (or 10 in the future). The installer being a web installer that auto-updates on start also means that downloading an older one doesn’t help at all. The only way seems to be to pirate the Enterprise offline installer which of course isn’t really an option.

Re: The tragedy of running an old Node project

#283

Post by horsawlarway »

jonathanlydall wrote: post #164
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

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

As someone who has migrated old ASP/silverlight projects and BHOs... seriously, this is complete bullshit.

This depends highly on what dependencies are in your C# solution.

Same for his node project. If he'd stuck with dependencies that are just plain js - I'd bet money his project would have installed & built just fine.

By the time you're hitting the native addon apis and doing things like compiling python and C/C++ code... you're going to feel all the pains of those ecosystems too.

Re: The tragedy of running an old Node project

#284

Post by trinix912 »

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

Pardon my ignorance, but wouldn’t that rule out most image processing packages that depend on (and often build during install) imagemagick as the backend? A long time ago I tried to avoid it in a project but really couldn’t find any decent node image processing package that wouldn’t at some point depend on it. Maybe I just didn’t look far enough?

Re: The tragedy of running an old Node project

#286

Post by Eric_WVGG »

melbourne_mat wrote: post #41

First thing I would have done is upgrade the version of Gatsby to latest. Did the author try that? If upgrading is difficult because of 4 years of breaking changes, blame Gatsby for not being backwards compatible. Also blame your original choice of going with a hokey framework. Speaking of hokey framework: 167 dependencies and 3000 versions of Gatsby in npm.

The first thing I would have done is check the version of Node.

That's a quick fix, upgrading a framework is a guaranteed min hour of poking around before the system is even running.

I dunno why `engines` isn't in every `package.json` file, would certainly have saved me hours of nonsense.

Re: The tragedy of running an old Node project

#287

Post by Eric_WVGG »

tomgp wrote: post #172
baq wrote: post #95

Earlier quoted context omitted.

blaming anything or anyone gets you exactly zero seconds closer to getting the job done.

You could perhaps reframe "blame" as identifying the source of the problem and iunderstand why it can be a useful excercise (aslo none of us here are trying to solve the problem really, just wasting time on the internet). In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue as they don't seem to have any interest in taming the No…

> In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue

I disagree completely. Regardless of what you think of Gatsby, Node versioning is a simple problem that affects nearly every javascript project. It should always be the first thing you check.

I made this dumb obvious mistake again just last week, looking for a little time to audit all my `package.json` files for `engines`.

Re: The tragedy of running an old Node project

#288

Post by liontwist »

regularfry wrote: post #259
liontwist wrote: post #245

Earlier quoted context omitted.

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

Which bit is it that you object to? Edit to add: this wasn't intended as a gotcha question, so apologies if it came across as one. I have issues with a lot of details about how npm works and the ecosystem it supports. I think it's possible to avoid them, and aim for something more like a bundler or a cargo, but again there are issues there (certainly in the former's case, I have less experience of the latter). Gettin…

Sure, I didn’t take that negatively.

Let me start with facts:

- npm actually downloads multiple copies of each library, when needed to satisfy conflicting version requirements. - this is only possible due toruntime features of JavaScript. In most languages like C this causes symbol collisions. - I think this is a problem in Common Lisp too due to packages being global. Maybe there is a fancy way to rebuild packages at load time. - this is why the Debian style release makes sense. Either everything loads together, or not.

Opinions - I want to know all my dependencies. I treat them as my own source, so tar downloaded is close to my mental model. - For c projects I usually have a make file with curl commands tied to exactly url. If I want to update I manually change the url. - quicklisp already has a nice way to make an isolated folder just containing your code and its dependencies to be loaded with asdf. It gets out of the way once you have downloaded your libraries.

Re: The tragedy of running an old Node project

#289

Post by thrw42A8N »

neonsunset wrote: post #205
me551ah wrote: post #202

Earlier quoted context omitted.

Not true for the entire C# ecosystem. I tried rebooting a Xamarin project I coded a couple of years ago. Had to spend weeks upgrading it cause Microsoft decided to discontinue Xamarin and force everyone to use NET MAUI

This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can down…

If you used pure Node.js, you wouldn't have any problems whatsoever, too.

Re: The tragedy of running an old Node project

#290

Post by wpm »

mst wrote: post #131
graypegg wrote: post #43

Earlier quoted context omitted.

I truly believe some flavour of "Javascript Classic" (some future state of JS before some big shift in syntax/mass migration to something else), C and x86 instructions will follow humanity for the rest of time. There will be javascript somewhere aboard the interstellar spaceships of the future, and we will still complain about it.

I think it was 'A Deepness In The Sky' that posited so many layers of legacy underlying the starship control systems of the era that one of the most crucial positions on a ship was that of 'Programmer-Archeologist.'

That sounds great. Added to my list.

I adore the idea of somewhere on the Star Trek Enterprise, underneath the isolinear chips, the EPS conduits, the warp containment field control mechanisms, somewhere, if you dig far enough, override enough, you can get an LCARS screen that is all black, with a small `$` in the upper left and a blinking text cursor, waiting for a command.

Post reply on HN