5 ms·

Which is why js package managers have evolved to allow you to force a specific version if you want, and allow you to lock the version number of transitive depen

Which is why js package managers have evolved to allow you to force a specific version if you want, and allow you to lock the version number of transitive dependencies. But at the end of the day, if a dependency that you want to use uses a poor dependency itself, then you should treat the whole thing as bad. Personally I'm happy that we have such widespread usage of packages in the js ecosystem, because it makes it easier for me to audit things. I can run a command and get the total number of dependencies that something I want to add comes with, the total number of lines of code it includes. I can have scanners that look for malicious packages and identify them quickly and easily (rather than searching the lines of code for a copy-pasted bug or security issue). Every time someone complains about there being "bad" packages on npm, it reads to me like someone complaining that shitty cars exist, and somehow the existence of shitty cars makes all cars bad...

WkndTriathlete 8y ago
The problem is the number of dependencies and the number of people you are (implicitly) trusting by using those dependencies. It's an overwhelming engineering burden for those industries that are required to do that type of 3rd-party software auditing. When I use Java, I can trust - at an organizational level - large blocks of 3rd-party code (e.g. Spring, Java SDK) and may even be able to get them to assume some liability via agreement if their repositories for their libraries are breached and malicious code is injected. Additionally, because those libraries do so much, I require many fewer other 3rd party libraries that I'm required to audit. When I use JavaScript, I don't necessarily get those advantages. (NodeJS on the server side has an SDK, so this point does not apply there, so this is mostly directed at browser UI development.) Sure, we may use a framework like Angular, but I don't necessarily have confidence that Google has audited the 600+ transitive dependencies that the Angular team has pulled in. Because of this, I don't think that Google is prepared to assume liability in the face of malicious software injection, which means (in industries requiring audits) that we need to track down each one of those 600+ transitive dependencies and audit each one of them.
- Klathmon 8y ago
  It's less about the number of "dependencies" and more about the raw amount of code you need to audit. If you are capable of auditing 1 100k loc package, why aren't you capable of auditing 100 1k loc packages? Once you have audited a specific version, you can either vendor your dependencies (which I always encourage), or at the very least can lock all transitive deps down which both npm and yarn do by default now. If you vendor your deps, upgrades/changes are as easy to audit as a single project as you can get a diff of what changed right there in your own system. Now I'll agree that auditing any large amount of code is extremely difficult, but it's not a problem you can solve by switching to another ecosystem, at best you'll just move most of the code outside the realm you decided you need to audit.
  - stefanfisk 8y ago
    Auditing doesn’t necessarily mean a full code review. For 10 large frameworks doing random checks might be enough for most use cases, but the equivalent method would require a lot more time for 1000 small libraries.

WkndTriathlete 8y ago

The problem is the number of dependencies and the number of people you are (implicitly) trusting by using those dependencies. It's an overwhelming engineering burden for those industries that are required to do that type of 3rd-party software auditing. When I use Java, I can trust - at an organizational level - large blocks of 3rd-party code (e.g. Spring, Java SDK) and may even be able to get them to assume some liability via agreement if their repositories for their libraries are breached and malicious code is injected. Additionally, because those libraries do so much, I require many fewer other 3rd party libraries that I'm required to audit. When I use JavaScript, I don't necessarily get those advantages. (NodeJS on the server side has an SDK, so this point does not apply there, so this is mostly directed at browser UI development.) Sure, we may use a framework like Angular, but I don't necessarily have confidence that Google has audited the 600+ transitive dependencies that the Angular team has pulled in. Because of this, I don't think that Google is prepared to assume liability in the face of malicious software injection, which means (in industries requiring audits) that we need to track down each one of those 600+ transitive dependencies and audit each one of them.

Klathmon 8y ago
It's less about the number of "dependencies" and more about the raw amount of code you need to audit. If you are capable of auditing 1 100k loc package, why aren't you capable of auditing 100 1k loc packages? Once you have audited a specific version, you can either vendor your dependencies (which I always encourage), or at the very least can lock all transitive deps down which both npm and yarn do by default now. If you vendor your deps, upgrades/changes are as easy to audit as a single project as you can get a diff of what changed right there in your own system. Now I'll agree that auditing any large amount of code is extremely difficult, but it's not a problem you can solve by switching to another ecosystem, at best you'll just move most of the code outside the realm you decided you need to audit.
- stefanfisk 8y ago
  Auditing doesn’t necessarily mean a full code review. For 10 large frameworks doing random checks might be enough for most use cases, but the equivalent method would require a lot more time for 1000 small libraries.