←back to thread

The tragedy of running an old Node project

(abdisalan.com)
272 points abdisalan | 1 comments | 18 Nov 24 18:24 UTC | HN request time: 0.227s | source
Show context
mvkel ◴[18 Nov 24 19:03 UTC] No.42175730[source]▶
> 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

replies(21): >>42175799 #>>42175818 #>>42175826 #>>42175846 #>>42176217 #>>42176305 #>>42176788 #>>42176958 #>>42181497 #>>42182299 #>>42182564 #>>42182778 #>>42183020 #>>42183093 #>>42183501 #>>42183725 #>>42184814 #>>42192770 #>>42193606 #>>42194518 #>>42211558 #
jonathanlydall ◴[19 Nov 24 12:09 UTC] No.42182564[source]▶
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.
replies(8): >>42182945 #>>42182967 #>>42183426 #>>42183534 #>>42183571 #>>42183855 #>>42184181 #>>42185862 #
me551ah ◴[19 Nov 24 14:04 UTC] No.42183534[source]▶
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
replies(1): >>42183621 #
neonsunset ◴[19 Nov 24 14:12 UTC] No.42183621[source]▶
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 download regardless, it will complain that it is EOL though) but it's an otherwise simple procedure.

For library code it's even easier - if you have netstandard2.0 target, it will work anywhere from .NET Framework 4.6.1 to the latest version without requiring any maintenance effort whatsoever.

On Windows, Visual Studio will happily work with .NET Framework 3.0 (which is ancient) and more.

replies(2): >>42185278 #>>42186681 #
thrw42A8N ◴[19 Nov 24 18:33 UTC] No.42186681[source]▶
If you used pure Node.js, you wouldn't have any problems whatsoever, too.
replies(1): >>42186905 #
neonsunset ◴[19 Nov 24 18:59 UTC] No.42186905[source]▶
Unlike Node projects, your dependencies don't break - they stay on nuget.org, and the projects compile just like they did when they were first implemented. Upgrading dependencies and project target is subject to the same restrictions as in other good languages.

I know for sure that I can clone a random project on Github, hit `dotnet build` and usually expect it to work on the first try. The rate of bitrot for average unmaintained JS project cannot be compared. The average dependency graph of a .NET project is going to be 10 times smaller too.

replies(2): >>42188629 #>>42191608 #
1. MrJohz ◴[20 Nov 24 07:42 UTC] No.42191608[source]▶
This is true for NodeJS as well - dependencies on NPM cannot be removed, so at long as NPM keeps running, and as long as you've got a lockfile that precisely specifies all dependencies, you shouldn't run into problems running older projects. (Certainly I have never had an issue with this - the problems, if they occur, are always around upgrading. And like you say, this is subject to much the same issues in every ecosystem).

If this isn't enough, there are tools like Yarn which encourage vendoring dependencies to ensure that as long as you have a copy of the repository, the yarn CLI, and a valid version of NodeJS, you can always run the project.