3 ms·

It's a good idea, but increasingly impractical. Npm-based development is just such a fractal of dependencies; it'd take me a year to review everything that goes

It's a good idea, but increasingly impractical. Npm-based development is just such a fractal of dependencies; it'd take me a year to review everything that goes into a typical SPA, and by the time I was done 90% of the packages would have been updated significantly. I just hope the various cryptominers that get shoehorned in to umpteenth child dependencies fight against each other...

iudqnolq 7y ago
I'm confused. I would think more modular work is easier to review, plus modules allow deduplication. Is a module with 500,000 LoC in dependencies really that much harder to audit than a project that includes the same code internally?
- thrower123 7y ago
  A project that has 500kloc probably doesn't have anywhere the churn on most of that code that actively developed dependencies have. Most of that mass of first-party code is static and doesn't change much, if ever.
- asdkhadsj 7y ago
  I think the issue is each module tends to include far more code than just what the project needed. If everything was like the NPM meme where you install a package to check if something is true, then your LOC for that module with be quite limited. However a single dependency is often big itself, and the 50 dependencies it has are also quite big. The LOC in the dep-dep is not the same as if it was written by hand in the dep. So if you wrote your dep by hand you may use, say, 500,000 LOC - but with the tree of dependencies not being a 1:1 to what you use, you have to audit more like 2Mil LOC. Perhaps an audit could be aided by some sort of tree-shaking scenario, where all non-used code is removed, leaving you with the real 500,000 LOC that needs review.. Would be interesting. I've been having this same problem with Rust lately. Frankly, I think it's true for any package platform you use.
  - droidist2 7y ago
    >I've been having this same problem with Rust lately. Frankly, I think it's true for any package platform you use. Right, people act like node_modules is extremely special. They open the folder and say "Look at all of the files, what a mess!" as if other languages don't have this. Just in most other languages it's more hidden from you.

iudqnolq 7y ago

I'm confused. I would think more modular work is easier to review, plus modules allow deduplication. Is a module with 500,000 LoC in dependencies really that much harder to audit than a project that includes the same code internally?

thrower123 7y ago
A project that has 500kloc probably doesn't have anywhere the churn on most of that code that actively developed dependencies have. Most of that mass of first-party code is static and doesn't change much, if ever.
asdkhadsj 7y ago
I think the issue is each module tends to include far more code than just what the project needed. If everything was like the NPM meme where you install a package to check if something is true, then your LOC for that module with be quite limited. However a single dependency is often big itself, and the 50 dependencies it has are also quite big. The LOC in the dep-dep is not the same as if it was written by hand in the dep. So if you wrote your dep by hand you may use, say, 500,000 LOC - but with the tree of dependencies not being a 1:1 to what you use, you have to audit more like 2Mil LOC. Perhaps an audit could be aided by some sort of tree-shaking scenario, where all non-used code is removed, leaving you with the real 500,000 LOC that needs review.. Would be interesting. I've been having this same problem with Rust lately. Frankly, I think it's true for any package platform you use.
- droidist2 7y ago
  >I've been having this same problem with Rust lately. Frankly, I think it's true for any package platform you use. Right, people act like node_modules is extremely special. They open the folder and say "Look at all of the files, what a mess!" as if other languages don't have this. Just in most other languages it's more hidden from you.