"added 242 packages from 179 contributors and audited 1098 packages in 13.598s"
how can I trust that this doesn't contain malicious code?
I've tried to be minimal with my dependencies while providing a rich user experience, but I'm sure we could do better still. Any dependencies in particular you'd like me to look into removing?
I don't really think npm is to blame in this specific case. It's merely acting as an index to a set of tarballs, e.g. the same way PyPI or crates.io do.
It would be fairer to point the blame at the ecosystem and mindset of developers of popular JavaScript libraries.
Other than that, I have to commend you on the rest of your dependency management; most of the rest of your chosen dependencies have between 0 and 3 sub-dependencies.
I guess you can use packages that use minimal dependencies, and pin those to specific versions.
Maybe look to convert to a language that doesn't do this? I realise that's a tough call, though.
The package uses functions from multiple packages, if they were to instead write them all themselves you may end up with 50,000 lines of code.
It's basically just split up amongst a bunch of different folders and files with a bunch of extra "garbage" and 99% unused code.
So if you don't trust it, read it all.
But at some point you got to trust something.
Sure, you can do locking, but that does not go deep well, and also turns into a hell of trying to determine if every (for your use-case) pointless release of a sub-dep is worth updating to.
PostgreSQL has 1257 source files [1], 1,250,000 lines of code [2], and ~400 authors [3].
So...however you'd normally audit that.
Probably look at the number of users, check for CVEs, and cross your fingers.
[1] find . -name '*.c' | wc -l
[2] find . -name '*.c' | xargs cat | wc -l
[3] git log | grep -o 'Author: \S\+ \S\+' | sort -u | wc -lThese dependencies are 242 projects, privately managed and unvetted.
I can choose to "trust" the PostgreSQL project, as it's a mature project with high visibility. I can't practically choose to "trust" those 242 projects and gauge the trustworthiness of 179 separate contributors; doing so would take vastly more time than most people have.
Dependency bloat is a huge and frustrating problem, especially for people who want to know where their code is coming from and don't want to have to decide to trust hundreds of people for a random cli tool.
So, firstly, Postgres takes responsibility for contributions. The fact that someone has submitted a patch or PR is no guarantee that it has been accepted.
Secondly, they combine all those contributors to release specific versions with specific features. I can trust that someone at postgres has reviewed all those contributions to ensure they make the grade and included them in the release for a reason.
Thirdly, Postgres as an institution takes responsibility for the code it releases. If I find something messed up in a postgres release, and report it to postgres, they will take responsibility for that and manage the rest of it.
None of this is true for NPM.