- First, if you're treating Gatsby as a generalized site builder, this is an audit you only need to do once for all of your projects. It's not, "I need to audit 760 modules to build a simple webpage", it's "I need to audit my site builder once before I adopt it for all of my projects".
Of course, NPM makes it harder to treat Gatsby that way, because NPM makes it harder to freeze the entire package and guarantee you're using the same code everywhere. This is honestly true of a lot of package managers, there is a lot of room for future ecosystems to do package management better to help mitigate some of this personal responsibility.
Just as an example, I didn't need to personally do a security audit of every one of Krita's dependencies when I installed it in Arch. I downloaded a version that someone else had vetted. NPM just makes this hard to do.
- Second, the simple webpage part here is a little misleading. Gastby.js isn't simple, it's doing a ton of stuff. So it's not like building a simple webpage requires 760 modules, it's that you're using a site builder that comes with its own web Express web server, that does code transpilation with Babel and Webpack, that includes a code linter.
Here's the list of dependencies for Gatsby.js: https://www.npmjs.com/package/gatsby?activeTab=dependencies. Understanding that this isn't "a very simple webpage" puts that number into perspective and starts to make that security audit look at least a little bit more reasonable.
The Node ecosystem doesn't require 760 modules to build a webpage. It requires 760 modules to build a development environment, and then it bundles that development environment as a dependency. That's a very different situation to be in.
>Should I be doing security audits on every single one of the 760 modules?
Yes, ideally.
I know this isn't practical. The fact that you have so many dependencies and any one of them could do something bad should be a sign that something is deeply wrong in the ecosystem.
The JavaScript ecosystem is famous for bloat like this. Python is much better, though there is still an O(n^m) dependency tree. Languages like C/++ and FORTRAN commonly have effectively O(n) dependency trees.
I suspect it’s related to the ease of use to add new libraries/modules.
It only has around 10 direct dependencies, but if I look in the node_modules folder...760 distinct modules required in the dependency graph.
Should I be doing security audits on every single one of the 760 modules?