Having CI would have avoided this problem.
Not for running the project locally
The tragedy of running an old Node project
191–200 of 412 posts
Re: The tragedy of running an old Node project
#192Having CI would have avoided this problem.
Not for running the project locally
I think you're missing the point.
CI solves it because it proves that it can build in the pipeline, using a well defined environment.
No guessing at which node version you need or any other dependencies that may be required.
Re: The tragedy of running an old Node project
#193> 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
> 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.
> Java
50% of Java developers are still regularly working in Java 8 [0], which is the same solution that the author could have arrived at immediately—when starting up an old project after 4 years, use the same version you ran last time, don't try to update before you even have the thing running.
> C, C++
Not my experience, but maybe it depends on your operating system and distro? In my experience sorting through the C libs and versions that you need to install on your system to build a new project can easily take a few hours.
Re: The tragedy of running an old Node project
#194> 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.
Lol, I left C# because I couldn't solve this issue and in Node.js it's particularly easy - just keep a nvmrc file and a dependency lockfile.
Re: The tragedy of running an old Node project
#195Earlier quoted context omitted.
This shocks me, what sort of issues do you hit?
+1 on this. I've been using Go almost exclusively for the last 5 ish years partly because this sort of thing never happens.
You lucked into the period when they solved the issues. If you need to work with older projects and can't easily convert them, you're going to have a bad time.
Re: The tragedy of running an old Node project
#196Earlier 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. Two hours of dancing with a drum doesn’t feel acceptable to me.
Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later.
Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
Re: The tragedy of running an old Node project
#197Earlier quoted context omitted.
I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`. Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an examp…
>Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by…
Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison.
Re: The tragedy of running an old Node project
#198> 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
It's also two hours that would have been completely avoided if the author were familiar enough with Node to know to pin the version and not try to install 4 years of updates in one shot.
Most who are here saying that X, Y, or Z ecosystem "compiles and runs" fine after 4 years are talking about the time it takes to resume an old project in a language they're very familiar with running the same dependency versions, not the time it takes to version bump a project on a language that you don't know well without actually having it running first on the old version.
I can open my 4-year-old Node projects and run them just fine, but that's because I use the tools that the ecosystem provides for ensuring that I can do so (nvm, .nvmrc, engines field in package.json).
Re: The tragedy of running an old Node project
#199Earlier quoted context omitted.
Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model. I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time. JavaScript has gotten better but it seems they are just re-learning things that were long figured o…
"Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem." We just had to workaround breaking changes in a patch version update of Spring Boot. Maybe it was true in 2005, but certainly not the case today. I know of products that are stuck in Java 1.8 and not because they are too lazy to upgrade.
I've been involved in bringing real old Java 1.4 and 6 and whatnot up to 17 and from classic app servers into cloud, can take a bit of work but it's pretty straightforward, mostly switching out deprecated methods to their successors and copying over boilerplate config from similar applications.
Re: The tragedy of running an old Node project
#200Earlier quoted context omitted.
Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model. I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time. JavaScript has gotten better but it seems they are just re-learning things that were long figured o…
In JetBrains's Developer Ecosystem 2023 survey, 50% of developers were still regularly working in Java 8 [0]—the exact kind of "stick with the old version of the runtime" solution described in TFA. [0] https://www.jetbrains.com/lp/devecosystem-2023/java/
Java 8 is 10 years old. If you had a project with a Java version that was recent 4 years ago (11 - 14), you could run it without any problems or changes.