Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

91–100 of 412 posts

Re: The tragedy of running an old Node project

#91
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…

You're talking about what's wrong with the NPM ecosystem, not JS.

Previously: You wouldn't conflate Windows development with "C" (and completely discount UNIX along the way) just because of Win32. https://news.ycombinator.com/item?id=41899671>

Re: The tragedy of running an old Node project

#93
post #86
post #69

Earlier quoted context omitted.

Getting the exact dependencies it had at release is a solved problem in Node and most other languages with lock files too. It's just no guarantee that those old versions work on the new system, or with the outside world as it exists by time of installation - which can be as true for Go as any other language. If the XYZ service API client still gets you version 1.2.37, that's not actually any help if 1.2.37 calls endp…

Some time ago, I wanted to update Arch, on a server running some python project I had inherited. Long story short, it relied on something that relied on something that etc., and then it turned out certain components that were needed for the upgrade process had been taken offline. Now the system can’t be changed, unless there’s significant work done to the code, and that’s too expensive. It runs on request in a contai…

back in the day you were supposed to check in your compiler into version control (not the lockfile, the whole distribution).

I used to think that people emailing screenshots of corporate dashboards were idiots. I now think that's actually genius - a frozen in time view which you can't regenerate but will be available until the end of time if you need it. (Hello, Exchange admins!)

Re: The tragedy of running an old Node project

#94
I had to build some project that uses some Ruby package manager. I forgot already what the package manager is called. I got some error about "you don't have all the dev tools". So I installed what Google told me "dev tools" was. Then it still told me that I needed more dev tools. Stackoverflow had some question about this package manager. For Windows (Linux here). 20+ answers, mostly for Mac. All in the style of "this random thing worked for me". All with at least one upvote. Some answer about "I needed to symlink this system library".

Gave up.

Then I ran `devbox init` and installed whatever it told me that was needed. `devbox shell`.

Re: The tragedy of running an old Node project

#95

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.

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

Re: The tragedy of running an old Node project

#97
post #92

Good old node-gyp. I have absolutely no idea what it even is but it has been giving me errors for what feels like a decade. Mostly via front end build stuff from various projects I have worked on

i forgot all about node-gyp. The only memories I do have of it are the errors and thinking about gimps.

Re: The tragedy of running an old Node project

#98
> node-gyp

We're in ... let's call it a transitional period at work. I've got something like a dozen versions of node being managed by asdf. And in half of the projects I work on regularly, I consistently get warnings about this particular project failing to build.

One day, I'll actually look up what it actually is, and what it does, and why it's being built, but is apparently optional.

Re: The tragedy of running an old Node project

#99
post #14

The worst part isn't just that it's nearly impossible to run/update an outdated JS project, but that this process will repeat itself ad infinitum. On the flip side, anything that uses vanilla JS without a build will most likely run just fine, probably till the end of human civilization.

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.

My grandchildren will live to see Vernor Vinge's programmer-archeologists troubleshooting PHP issues on the Wordpress install responsible for life-support around Alpha Centauri.
Post reply on HN