Clickbait. At least propose what it is that you think needs to be done to address this so-called chaos.
Worth noting that ES2017 added String.prototype.padStart and String.prototype.padEnd. The whole left-pad thing is blown out of proportion.
Second, you shouldn't be relying on npm for deployments. You dig your own grave. If package deletion is a concern, then host a mirror with something like Nexus [0], or pay for a service [1] [2] to do it for you. Over the years there have been a few local npm mirror tools [3], but I don't think any of em have really caught much traction. There's also the option of bundling each release. For that you can use a tool such as Webpack [4], or take it one step further and generate a single binary using something like pkg [5].
Developers also have the option of forking their dependency graph and updating references in package.json. Sooner or later you'll start to find bugs in your dependencies and have to fix them. It's your responsibility, you own all that code. Don't be afraid of maintaining your own fork. If you find a critical issue you'll probably need to be able to deploy your update without depending on a third-party anyway. This is fairly common in other ecosystems. Heck, you can also just check in your node_modules folder into version control.
Don't get me wrong, npm certainly has its fair share of problems, and historically they haven't had the best defaults... But there's usually ways to work around the issues, and they're gradually working towards improving things. It's the developer's responsibility to handle their ecosystem's problems, which is also nothing new in the world of software development.
It's the developer's responsibility to handle their ecosystem's problems, which is also nothing new in the world of software development.
This is where you have to start questioning the benefits of using node/npm/js on the backend. We're all stuck with it on the front end for the foreseeable future.
I've never had any of the problems in node/npm using NuGet/C# for example.
At some point, I raised my hands and emailed my boss about a new project using node, essentially saying "this is dumb. left-pad is dumb. is-number is dumb. is-odd is dumb. the amount of packages depending on these is dumb. And I won't be arsed to fix it because I value my time, so I'd rather just jump back to an ecosystem that has its shit together because the result is the same simple API pushing json either way we go."
node/npm sucks IMO. Sorry, but the problems I have to fix daily are not interesting, and conquering the mountain and being able to say I fixed all those every-day problems with it is not worth much on the job market.
If the amount of web backends suddenly needs node because they suddenly stop pushing json all day long, because node/npm is the only ecosystem that offers that solution, then you have a compelling reason. But other languages do json APIs just fine right now and have less ecosystem paper cuts.
I personally recommend caching package tarballs locally inside your project [0], using either Yarn's "offline-mirror" feature, or if you're using NPM, a tool called Shrinkpack [1]. Might not be the best fit for every project, it but it guarantees reproduceable installs without having to go out to NPM's servers.
Comments
Clickbait. At least propose what it is that you think needs to be done to address this so-called chaos.
Worth noting that ES2017 added String.prototype.padStart and String.prototype.padEnd. The whole left-pad thing is blown out of proportion.
Second, you shouldn't be relying on npm for deployments. You dig your own grave. If package deletion is a concern, then host a mirror with something like Nexus [0], or pay for a service [1] [2] to do it for you. Over the years there have been a few local npm mirror tools [3], but I don't think any of em have really caught much traction. There's also the option of bundling each release. For that you can use a tool such as Webpack [4], or take it one step further and generate a single binary using something like pkg [5].
Developers also have the option of forking their dependency graph and updating references in package.json. Sooner or later you'll start to find bugs in your dependencies and have to fix them. It's your responsibility, you own all that code. Don't be afraid of maintaining your own fork. If you find a critical issue you'll probably need to be able to deploy your update without depending on a third-party anyway. This is fairly common in other ecosystems. Heck, you can also just check in your node_modules folder into version control.
Don't get me wrong, npm certainly has its fair share of problems, and historically they haven't had the best defaults... But there's usually ways to work around the issues, and they're gradually working towards improving things. It's the developer's responsibility to handle their ecosystem's problems, which is also nothing new in the world of software development.
[0] https://www.sonatype.com/download-oss-sonatype
[1] https://jfrog.com/artifactory/
[2] https://inedo.com/proget
[3] https://github.com/rlidwka/sinopia
[4] https://webpack.js.org/
[5] https://github.com/zeit/pkg
This is where you have to start questioning the benefits of using node/npm/js on the backend. We're all stuck with it on the front end for the foreseeable future.
I've never had any of the problems in node/npm using NuGet/C# for example.
At some point, I raised my hands and emailed my boss about a new project using node, essentially saying "this is dumb. left-pad is dumb. is-number is dumb. is-odd is dumb. the amount of packages depending on these is dumb. And I won't be arsed to fix it because I value my time, so I'd rather just jump back to an ecosystem that has its shit together because the result is the same simple API pushing json either way we go."
node/npm sucks IMO. Sorry, but the problems I have to fix daily are not interesting, and conquering the mountain and being able to say I fixed all those every-day problems with it is not worth much on the job market.
If the amount of web backends suddenly needs node because they suddenly stop pushing json all day long, because node/npm is the only ecosystem that offers that solution, then you have a compelling reason. But other languages do json APIs just fine right now and have less ecosystem paper cuts.
I personally recommend caching package tarballs locally inside your project [0], using either Yarn's "offline-mirror" feature, or if you're using NPM, a tool called Shrinkpack [1]. Might not be the best fit for every project, it but it guarantees reproduceable installs without having to go out to NPM's servers.
[0] http://blog.isquaredsoftware.com/2017/07/practical-redux-par...
[1] https://github.com/JamieMason/shrinkpack