Yeah, I use https://github.com/nvm-sh/nvm
I always approach any library upgrade as a potential disaster that'll result in me having to nuke my entire node setup for that project and rebuild it from the ground up or last known good state. I never had the kinds of problems I have with JS with any other bloody languages and their respective build tools.
Now, using the "engine" and "packageManager" properties in "package.json", you can bind your project to a particular runtime version and package manager.
lmao
npm (Node Package Manager) pnpm being a modified version thereof that adds a compression/content addressible store mechanism to speed things up in a development configuration. Or Yarn
...which is yet another dependency management solution cum build tool, which is Maven/Gradle like. Depending on version though there are so many quirks. Both are "staples" of any enterprise scale project I've run into.
I don't have an issue with nodeJS or JS per se. It's the ecosystem and enterprise tooling. I still cannot for certain say those damn build tools don't muck things up in horribly subtle ways, and the experience of debugging the average horrible nest of every dependency known to man has comsumed entirely too much of my life, and the experience overcoming that learning curve I still can't say with confidence wasn't somewhat deleterious to my personal sanity.
I can do it trivially now; and I can appreciate the things you can build with it when doing it correctly. The depth of hole you can quickly end up in though is not to be underestimated.
That and nigh every JS developer I've run into who says they are proficient knows nothing about really debugging it, or hasn't read the core library docs and really means they can use one framework or another.
...Bar like 3. Who you never want to bother, because they are usually handling issues way more important/wide-ranging that warrant their attention than hand-holding you through learning how it actually works.
None of those things (package-lock.json, node_modules, or p?npm|yarn) actually come from ECMA-262...
I'm surprised, the only node package manager that has any semblance of sanity is pnpm.
No flattening BS. Not randomly adding extraneous undeclared dependencies on the dependency tree. Not allowing random dependencies to depend on extraneous undeclared dependencies on the dependency tree.
Of course, then you find out that in the real life people actually use other package managers, and depend on non-deterministic, package flattening behavior and extraneous undeclared dependencies requiring extraneous undeclared dependencies...
That said, yea, the JS ecosystem is literal cancer.
How we got ourselves here, I don't know.
Then SV happened, and the web became Serious Business. Then Node.js happened and Javascript became Serious Business, and with that came the byzantine horror of complexity necessary to get a toy scripting language invented in a week to replace every enterprise programming language in existence because managers could toss a rock out of their office window and it would bounce off of three web devs before hitting the ground.
BASIC would like a word.
Heck, even Python came 4 years before JS.
I find JavaScript's type system to be horrendous and bug prone. I'd rather operations between two types that don't make sense (like dividing an Array by an Object) to throw an explicit error than to just do some unpredictable shit that causes a subtle bug.
Also, BASIC is probably the easiest language to learn, though this is mostly because it lacks capabilities that create complexities. It's a completely obsolete language.
Nowadays everyone has 10 JavaScript interpreters in every device, so it's much more accessible than finding out about and installing BASIC.
BASIC also lost all relevance in terms of actually being useful (if it ever had it), whereas JS is the bee's knees.
FTFY.
The most likely opposite to "basically invented overnight" is "designed by committee", and is that much preferable?
Origin stories aren't the end of the story either. Humble origins aside, JS has had many of the best minds in many of the largest companies contribute all sorts of feature work and performance efforts across a span of decades. How many languages can claim that many eyeballs and that diverse a set of language developers and engine writers?
Sure, a lot of it looks like a hodgepodge, especially with its mandatory, deep respect for backward compatibility, because no one wants to break an old website. But show me the language with any respect for backward compatibility that doesn't look like a hodgepodge?
Core systems languages like C and C++ started out as intentional hodgepodges. Their macro system was originally its own, different, language brought in from another existing project for some temporary duty, and now enshrined in the language as a forever feature.
Hodgepodges are how languages are built and evolved. That's how we got ourselves here: the natural way. Every programming language on the planet is its own beautiful house of cards, built piece at a time. Don't just look down on JS because it went "mainstream".
(ETA: I am a fan of Common Lisp, for what that is worth, if this sounds too critical. It's a very nice language. Some of what has made it nice was a massive committee and standards effort, very similar to the way JS has continued to evolve under TC-39 stewardship.)
Also yeah, my impression of Java was that it was very design-by-committee.
Roughly "overnight" for six years:
It's the only language I've written in where no matter what code I'm writing, I can always think "this could be fully generalized and spun out into a package"