[dubcanada]

Well the obvious way is to look through every line of code.

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.

[SahAssar]

The part you leave out of that explanation is that for those files and folders there are 179 authors to trust for all future changes (including adding more authors via granting access to their repo or adding more deps).

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.

[marcus_holmes]

This. am I really expected to review every change that 179 authors make to 242 packages?

And if I don't, am I responsible for the malicious code insertion, or is NPM going to take responsibility for that?

[SahAssar]

You are responsible for malicious code insertion either way.

If you delegate trust in any way, you are responsible for how that trust was (mis)used.

[techntoke]

This is why the JavaScript ecosystem is broken as a whole