And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did.
And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You need both to stay sane.
And of course somebody will do something dynamic that will open a security issue.
And of course typo squatting is going to be so much easier.
And removing a bad lib ? From npm you signal the admin. When it's on it's own domain ? Good luck.
And then searching for libs is going to be fun. And naming, naming will be amazing.
And having a quick glance at the dependency of a lib ? So much fun.
And wait for the search/replace in the code that will change your entire run time by mistake.
And no possible alternative package manager. Hope their dependency resolver never sucks cause you will be stuck till you can install the next node... if they ever fix it.
Ah, and the git blames to see what dependencies have changed are going to be just peachy.
Oh, and your juniors copy/pasting code from the net is going to get extra crispy.
But wait, running the code on conditional imports means your project may install something at ANY moment in its life cycle. And could be changed by somebody editing the code by mistake without really asking to change a depandancy. You know, like a ctrl + D on "0.1" to replace all those floats quickly.
Also cool URLs don't change. Until they do. Tiny URLS dependencies are going to be hilarious.
I could go on and on and on and on...
I can't understand how you can be intelligent enough to code freaking node JS and not see THAT elephant in the doll room.
You are imagining the worst possible execution of these ideas. Nobody is proposing that you should start using libraries that pull in code from random domains, unless you have some specific need to. Whitelisting sources is such an obvious step, given the security focus, that you should really have applied the https://en.wikipedia.org/wiki/Principle_of_charity in your speculation.
Not OP, but a couple guesses off the top of my head:
* It becomes a more painful process to upgrade dependencies (have to find/replace across your codebase).
* Many versions of the same library get pulled in. If you depend on package@1.5.3 and a dependency of yours depends on package@1.5.4, that's twice the dependency size as compared to both just using 1.5.4. This matters more in the case of web app bundle size though than running local programs.
You could have an entry file for your dependencies (let's say dependencies.ts) and reexport everything from there.
When you have to update, you only have to upgrade it in the entry file and you can avoid multiple versions.
And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did.
And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You need both to stay sane.
And of course somebody will do something dynamic that will open a security issue.
And of course typo squatting is going to be so much easier.
And removing a bad lib ? From npm you signal the admin. When it's on it's own domain ? Good luck.
And then searching for libs is going to be fun. And naming, naming will be amazing.
And having a quick glance at the dependency of a lib ? So much fun.
And wait for the search/replace in the code that will change your entire run time by mistake.
And no possible alternative package manager. Hope their dependency resolver never sucks cause you will be stuck till you can install the next node... if they ever fix it.
Ah, and the git blames to see what dependencies have changed are going to be just peachy.
Oh, and your juniors copy/pasting code from the net is going to get extra crispy.
But wait, running the code on conditional imports means your project may install something at ANY moment in its life cycle. And could be changed by somebody editing the code by mistake without really asking to change a depandancy. You know, like a ctrl + D on "0.1" to replace all those floats quickly.
Also cool URLs don't change. Until they do. Tiny URLS dependencies are going to be hilarious.
I could go on and on and on and on...
I can't understand how you can be intelligent enough to code freaking node JS and not see THAT elephant in the doll room.