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

331–340 of 412 posts

Re: The tragedy of running an old Node project

#331

Post by jcelerier »

Etheryte wrote: post #151

Can't help but feel that this is a massive nothing-burger. You wouldn't generally expect your Java project to run if you use an incompatible version of the JVM, nor would you generally expect your C++ project to build if you swap one compiler for a different one. Etc, always specify what your project relies on, whether it's in the readme or in the dependency tree.

> nor would you generally expect your C++ project to build if you swap one compiler for a different one.

it's absolutely the expectation for C++ projects to support building on GCC, Clang and MSVC

Re: The tragedy of running an old Node project

#332

Post by [deleted] »

rootnod3 wrote: post #10
jerf wrote: post #7

Earlier quoted context omitted.

One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa. It's OK. Not every language ecosystem is so busted t…

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.

[deleted]

Re: The tragedy of running an old Node project

#334

Post by Etheryte »

jcelerier wrote: post #331
Etheryte wrote: post #151

Can't help but feel that this is a massive nothing-burger. You wouldn't generally expect your Java project to run if you use an incompatible version of the JVM, nor would you generally expect your C++ project to build if you swap one compiler for a different one. Etc, always specify what your project relies on, whether it's in the readme or in the dependency tree.

> nor would you generally expect your C++ project to build if you swap one compiler for a different one. it's absolutely the expectation for C++ projects to support building on GCC, Clang and MSVC

Maybe these days this is the case, last I used C++ about a decade ago though, this was most definitely not guaranteed to be so. This thread [0] is a good quick overview of the type of issues you used to run into, and often you didn't even need anything fancy to hit those edge cases. If life has improved in the meanwhile, that's good of course.

[0] https://stackoverflow.com/q/51866968/1470607

Re: The tragedy of running an old Node project

#336

Post by switch007 »

shepherdjerred wrote: post #324
z3t4 wrote: post #314

You should save your deps in your SCM! Microsoft is giving away ownership to existing packages if you tell them you will use it for a TypeScript project.

What? Does Microsoft control npm?

Yes. npm is a subsidiary of GitHub, a subsidiary of Microsoft

Re: The tragedy of running an old Node project

#337

Post by vivzkestrel »

RadiozRadioz wrote: post #212

I call this phenomenon "node rot". Judging by the comments here, it seems like a universal experience. My favorite is the way that Python projects rot. Not only does Python's setuptools give you all the fun that node-gyp does, the common practice of versioning packages with packagename>=1.25.5 means you're almost guaranteed breakages as pip installs newer versions of packages than what the project was built with.

did you experience this breakage using poetry too?

Re: The tragedy of running an old Node project

#338

Post by vivzkestrel »

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.

one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly

Re: The tragedy of running an old Node project

#339

Post by KronisLV »

nitwit005 wrote: post #298
KronisLV wrote: post #217

Earlier quoted context omitted.

> I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's ano…

Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java. The company I work at has a ton of projects stuck on ancient spring versions and Java 8 (or Java 6 in one instance). They still insist on Spring despite being essentially unable to upgrade to a version newer than a decade old.

> Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java.

That's the reality of using the language in production projects.

Same as how you're likely to see more than just Python or Node being used in projects that list them in the tech stack, because there's native dependencies and tooling used.

Re: The tragedy of running an old Node project

#340

Post by speedgoose »

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

one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly

That would be a good argument to not implement authentication again and go with a solid authentication and authorisation software like Keycloak, Zitadel, or Ory Kratos.
Post reply on HN