I would just like to disagree on the "high quality" of modules. Personally I worked for a year in a very long lasting project about a specific type of social network. In the team I was the first one to push for the use of nodejs, react and mongo and... my god if I regretted it.

The quality of node package is very bad in general. Like the most part are totally garbage. I don't know from where you come and what you used before, I worked only with java, php and ruby for the backend and in those i found:

- far higher Documentation quality... like, node modules documentation is not even REMOTELY comparable: it is often extremely outdated, with very poor examples, the most of the times these example are not even working or are using functions deprecated since 3-4 versions of the module itself.

- a infinite amount of bugs and undocumented behaviors rarely already reported and, when reported, just ignored for months. I usually would find infinite workarounds instead of solutions

- extreme use of "I can do it better, so here my fork". I passed the big part of the time running from bug report to bug report and reading in the comments discussions about "The main maintainer of this package does not want to solve this problem of mine... so i made this other module, totally identical to this one but I just added this little hack, which totally broke the standard way of doinf things of this module, some functionalities I needed and never implemented the last 8-9 months of commits here." and chain this. Like this happened a dozen time each months when someone suggested "Why we don't try this module that says it solve our needs?"

- No standards anywhere.

Maybe your team chose bad modules? You seem to know what a bad module looks like (bad docs, bugs, many forks, hanging PRs, undocumented behaviour), so why did your team use ones like that?

It's true, you have to be careful ... there are so many npm modules that there are many garbage ones too. But there are many very high quality ones too. Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app. But in my experience there are high quality modules available for the major components of apps.

> But there are many very high quality ones too.

Doesn't mean there are any 'high-quality' ones appropriate for the specific task.

> Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app.

So now you're just contributing to the problem of yet another package in the ecosystem?

> Doesn't mean there are any 'high-quality' ones appropriate for the specific task.

Yes, which is why I said if you can't find one then roll the feature yourself.

> So now you're just contributing to the problem of yet another package in the ecosystem?

Nope, I didn't say write and publish a npm module. I said "roll the feature yourself", meaning just write it privately for your app. Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant.

> Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant.

Having an ecosystem where, say, 70% of the choices I make can be 'bad' is probably not a great ecosystem. I hope it shakes out in the next year or so and there's less choice. There's enough choices I have to make in my own application layer - having to make X more choices about code I didn't write and how all those pieces fit together (and how they'll be maintained going forward) just doesn't feel like a good long-term platform. But... people have the 'choice' to use it if they want ;)

Reducing the friction to publishing portable inter-related code modules to the world to near zero like npm has is an incredible thing. Everyone is still trying to understand the ramifications. The downside is that there's more garbage on there, but believe me, restricting your choice of module to the 30% of high quality ones is a trivial task for a experienced dev. If you want to criticise the platform on the basis that inexperienced devs use it and mess up sometimes that's up to you, but it seems pretty reductive.

I've heard a lot of observations about npm, but being unduly burdened with quality in package management has not yet been one of them!

Bundler and hex, for example, are faaaar better--just consider how long it took them to figure out shrinkwrapping, or flat structure to support Windows.