Professional java developers use a maven file which is similar to a package.json file. And it lists dozens of dependencies.

Even though java has default collections (so does javascript by the way), most developers also want Apache Commons (which could be compared to lodash)

And by default java has no DI and IOC, so most of them will install Spring Boot. The thing is, spring boot isn't just 1 dependency. There is actually a spring boot initializer website to help developers pick their dependencies. On top of that the names of Spring dependencies change between releases, sometimes they move things around.

And about persistence. In java you would need a JDBC library for ms sql server for instance. However, there are different ms sql server jdbc libraries depending of the version of the database, and depending on the version of your JRE. And in some cases you need additional libraries to add security protocols. (e.g. "bouncy castle")

And then there's JAXB which used to be included in the java framework, but has been removed since JDK8. Talk about backwards compatibility.

And what about portability. If you want to make a setup utility or installer for your software, then often they will include a copy of the Java runtime inside the installer. After all, you can't expect users to have java pre-installed. That does mean, that every installer has a footprint of 400MB+ (~the size of a JRE).

Node.js isn't that terrible now, is it?

In my previous role we constantly ran into issues with the integrity hash changing which was an unfortunate side effect of both the issues I mentioned above, an Artifactory npm registry and inconsistent npm/node versions

TL;DR though, it's not normal for the package-lock to change all the time.

In some of the nodejs projects I've worked, we had allu dependencies with pinned version numbers, and each week we created a ticket to track work on upgrading them. This typically involved a single commit updating package versions and running all tests. More often than not it took no work at all.

If a project just lets their dependencies change randomly and does not invest any work updating them, of course there's bound to be pain and suffering.

Building and bundling for the web platform (where you have multiple browser, environments, users on different versions) is a real challenge and you actually want to have good tooling for this.

With NPM, you just bundle all of the tooling along with the dependencies you need for your actual app.

I think that's still a big improvement over projects where you first had to setup your dev environment in very specific ways just to get started (I remember this could even take days to get right for some projects I worked on).

Although I would really wish for a better standard library, or at least some "core NPM modules" which are officially agreed upon, promoted and security checked as an almost-standard-library.

Sounds like a bad choice of tools for a person who's is concerned that much about the disk size.

a strong 'stdlib' is a must, no other code will pull in who-knows-what packages hundreds of MB at least. Just like javascript is badly design, so does nodejs.

Like if there’s some string manipulation thing I need, instead of copy pasting some snippet, I can pull in the micro package that already does this

That's not even what's important though. What's important is, how can you ensure that none of these things happen to any of *your* projects dependencies? It's virtually impossible when there's a thousand of them. Are you going to audit that string manipulation micro package when you first add it, and then for every version update from now on, to ensure that nobody slipped some subtle malicious code into it? And do the same for every other micro package in your project, including all of the ones that the big ticket packages depend on?

All of this would be much less relevant if it had a more fully-featured standard library.

However in Rust I find these packages managed properly which npm should learn.

More like "which the JS/TS developers should learn from"

npm is just a package manager, it's not its fault.

I know that ecosystem fairly well, and have found it pretty effective to develop in. Compared to that, we have vanilla JS, which is okay for a thing or two, but awful to make a full SPA in. Or probably like 20 other web UI frameworks, all of which probably do the same thing as far as dependencies and have a learning curve for how to use them.

And what do we mean by "enterprise" here? The issue is the dependency chains and the maintenance issues that causes. If it was really "enterprisey", you'd think they'd do a better job of having a manageable dependency chain.

Also, it's a safe bet in case the project grows beyond the initial scope. You don't want to spend most of your time refactoring, do you?

The same goes for TypeScript—how many interfaces does that app really have? Is it used in strict mode or just to type the most critical things?