Verify what? I certainly don't have the capacity to thoroughly review my every dependency's source code in order to detect potentially hidden malware.

In this case more realistic advice would probably be to either rely on a more popular package to benefit from swarm intelligence, or creating your own implementation.

▲

bdangubic 5 hours ago | parent [-]

also scrutinize every dependency you introduce. I have seen sooooo many dependencies over the years where a library was brought in for one or two things which you can write yourself in 5 minutes (e.g. commons-lang to use null-safe string compare or contains only)

	▲	notKilgoreTrout 5 hours ago \| parent \| next [-]
		Sure but you basically need a different ecosystem to bring in a popular package and not expect to end up with these trivial libraries indirectly through some of the dependencies.
	▲	user34283 5 hours ago \| parent \| prev [-]
		Said scrutinizing from my side consists of checking the number of downloads and age of the package, maybe at best a quick look at the GitHub. Yes, I'm sure many dependencies aren't very necessary. However, in many projects I worked on (corporate) which were on the older Webpack/Babel/Jest stack, you can expect node_modules at over 1 GB. There this ship has sailed long ago. But on the upside, most of those packages should be fairly popular. With pnpm's dependency cooldown and whitelisting of postinstall scripts, you are probably good.