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

121–130 of 412 posts

Re: The tragedy of running an old Node project

#121

Post by lmm »

hathawsh wrote: post #45
mattgreenrocks wrote: post #32

Earlier quoted context omitted.

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

I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated vers…

> That's not because there's anything wrong with Python

It's absolutely because there's something wrong with Python, the package management, and also the type safety. JVM languages haven't had these problems for 20+ years.

Re: The tragedy of running an old Node project

#122

Post by regularfry »

Ameo wrote: post #112
elashri wrote: post #110

Earlier quoted context omitted.

You can't use 'pip install' in debian because they chose to do that during the transition from python2 to python3. You should use 'pip3 install' which is provided by package python3-pip from debian. One can argue that this decision should be revised by debian but you should not install packages on system python installation for working into projects. Always use virtual environment.

No that does not work either. You get an error like this: » pip3 install supervisor error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with oth…

My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system.

Re: The tragedy of running an old Node project

#123

Post by regularfry »

mvkel wrote: post #115
korkybuchek wrote: post #33

Earlier quoted context omitted.

> 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.

Define "better experience." 1.5 hours to get running again? 1? In exchange for needing to run C? How many hours would it take to build a Node app equivalent in C, I wonder.

0 would be fine. I'd take 0. This could all have been avoided if the interpreter version had been recorded by default somewhere. That's all this needed.

Re: The tragedy of running an old Node project

#124

Post by regularfry »

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…

Clojure too, by all accounts. I'd say Common Lisp but they're in the weird position of code itself being rampantly portable across time but the ecosystem around it being astonishingly immature.

Re: The tragedy of running an old Node project

#125

Post by skeletal88 »

Ameo wrote: post #75
fourseventy wrote: post #62

Earlier quoted context omitted.

Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...

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

Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages. Python has a very rich standard library. You can do a lot with libc, if you had a c++ Qt project then it would provide you with basically everything you could ever need.

Re: The tragedy of running an old Node project

#126

Post by pzmarzly »

arp242 wrote: post #56
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

Well, the "solution" ended up as "I gave up and just installed an old Node version and called it a day". So those 2 hours weren't even enough. I've been using Jekyll/Ruby since 2014 for my website, with a few custom plugins I wrote myself. And I've never really needed to do anything like this. It "just works". My Go and C programs are the same: "just works". I have some that are close to a decade old.

Good for you, my experience with Jekyll is closer to OP's experience with Node. I have a big website that I built in 2014, with tons of custom plugins, that is now stuck on Jekyll 2.x and Ruby 2.x, and has a ton of hidden C++ dependencies. The way I build it now is using a Dockerfile with Ubuntu 18.04. I probably could update it given enough effort, but I was rather thinking of rewriting it in Astro.js or Next.js.

Re: The tragedy of running an old Node project

#127

Post by iamsaitam »

At first I thought it would be a decade old project, but 4 years isn't old by any standards is it?

Anyways, npm ci should have been the first attempt, not npm install so that it installs the same package versions defined in the package-lock.json. Then as others have mentioned, pin your node versions. If you're afraid of this happening again, npm pack is your friend.

In the end, op could have done a bit more. BUT I'll give it to him that when bindings are involved, these things take more time than they should

Re: The tragedy of running an old Node project

#128

Post by Aeolun »

You spent only two hours on this and you think it’s too much?

Also, do not run shit on a node version that is years out of date and out of service. Also, update your damn packages. I know I sound cranky, but running anything internet facing with god knows how many vulnerabilities in is an exceedingly bad idea.

Re: The tragedy of running an old Node project

#129

Post by Aeolun »

arp242 wrote: post #56
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

Well, the "solution" ended up as "I gave up and just installed an old Node version and called it a day". So those 2 hours weren't even enough. I've been using Jekyll/Ruby since 2014 for my website, with a few custom plugins I wrote myself. And I've never really needed to do anything like this. It "just works". My Go and C programs are the same: "just works". I have some that are close to a decade old.

Every single time I clone anything Go, I first spend a few hours sorting out dependency issues.
Post reply on HN