NPM tends to reinforce the worst of the JS world's tendencies.
Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?
> vast majority of JS developers don't seem to be aware of the rest of the software universe
Forgive me if I dismiss this as business-as-usual JS bashing
I dislike the microdependencies and the "DRY-taken-to-the-extreme" stuff that the js community does but your argument does not hold up.
Fibur = Thread
1)All packages that are published can never be unpublished or re-released from a different contributor
2)Packages are namespaced
3)Nobody downloads packages directly from the internet. You always use a proxy which in most companies has security scans.
4)There are no "local packages" (like the node_modules dir), so it is impossible for the checked out source code to override your own vetted and secure package.
Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages
2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation.
3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also use an internal proxy for npm, but it is obviously additional infrastructure to setup/maintain which has a cost.
4) Never heard anyone raise this as a problem before.
> Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages
You can't, with the exception of a 72 hour window, to allow for accidental publishing [1].
2) Again, whoever thought that namespaces should be optional instead of required "doesn't seem to be aware of the rest of the software universe". Who took this decision? Why?
3) Do a survey on your own. Ask Java developers you know if they use Artifactory/Nexus in their job and note down the percentage. Then ask the same question to JS teams
4) Just because something hasn't been exploited yet, doesn't mean it shouldn't be fixed. By that definition if left-pad hadn't happened would you say that (unpublishing) packages has not been raised as a problem yet?
2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.
3) I'm not the person blanket attacking a community. Or making unlikely assertions that "nobody" in the Java world installs direct from the internet.
4) Detail the exploit, otherwise this is FUD.
The above scenario is impossible with maven, because there is no concept of local modules. Only the "global" ones will be used when you package an app. So if you check just the source code and it is safe then everything is fine.
If the source was checked carefully, you'd notice a checked-in node_modules dir.
If you didn't check the source properly, you could install a module that seems like it'ss using a known package, but really is using its own malicious version of the global package.
If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages.
> and reinventing the wheel
I didn't mention reinventing the wheel.
> I'm not sure what words mean anymore.
Agreed, but i'm not sure i can help you with that.
If so, that's interesting, but then my question is why we didn't make use of that.
That being said, Cargo would also have to understand it, because the Rust language does not understand namespaced external packages, so you'd either have to change the language, or change Cargo to do something to paper over that somehow.
As for "why didn't we do this in the first place with crates.io", https://internals.rust-lang.org/t/crates-io-package-policies... lays out some of this background, though not all of it.
> When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands.
I will never stop admiring your ability to see the bright side of things.
Wrong.
None of them have chosen the "micro-package" way of NPM.
None of them have an average size of "3-10" line of code per package, which NPM has for many MANY packages. Cargo, pip have many packages but "reasonnable size" packages. ( > 100 lines ).
The Micro-package philosophy that NPM chose, meaning every single line of code can have its own package, increase by several factor the number of dependencies required to create anything in JS.
A simple hello world in react already have ~100 dependencies
https://npm.anvaka.com/#/view/2d/react-create-app
Some core utility bundler/packer/etc overpasses 2000 dependencies
https://npm.anvaka.com/#/view/2d/webpack
This is madness.
It is a simple evidence that bigger the dependency tree is, higher the chance of "one element" malicious / corrupted is.
Maybe the NPM developpers / users should reflect on what lead to this situation instead of closing their eyes and sing "everything is fine".
This is not something inherent to npm itself, it's what the people using npm choose to publish.
No matter if people like small modules or not, it's not at all related to the topic discussed.
It is very relevant to the topic discussed.
Just for fun :
https://npm.anvaka.com/#/view/2d/purescript
> 150 dependencies.
Including a package named "one-time", bundled several times in two different versions. To do something highly relevant and technical like "Call a function once".
I have no doubt that it is an Highly complex code that requires indeed two packages..... Irony
Little question: What would have been the probability of purescript getting malicious if its dependency tree would be something reasonnable... Let's say 20 packages instead of the current ~200 ?
The crab-grass like dependencies of many/most NPM packages is scary enough, and then they (or you?), I guess because of lazy loading, to improve responsiveness, update it as you watch.. It's like a scene out of an alien monster movie, where the creature keeps growing more limbs.
I know it's hard for you to imagine, but perhaps the JavaScript ecosystem has some good things about it.
There is good in very ecosystem. But a simple keyword "node_modules" on twitter should probably convince you that the good of JS is not in its package system.
To be fair, even the NodeJS author agree on that.
Modularity does not mean "split your code at the atomic level".
The language would not be worth using without it.