Widen the horizon - also affects live web, GoLang, Perl, Rust, etc.
I fully agree with sentiments regarding the typical Javascript eco-systems with regard to pulling in miscellaneous dependencies without review although I feel the language itself (sans strong typing) is as good or bad as any other, depending on the project requirements.
I get most upset by 'live' dependencies in web-sites to third party served code - the code being served can be trivially modified by the server based on the requesting user agent identity, IP address, and other heuristics, to deliver a highly targeted malicious payload that the web-site/application developers could never trigger.
For $deity's sake copy and serve the verified code/resource to your own server on the same domain as the primary resource!
However, a similar dependency eco-system exists with Rust crates and GoLang imports.
I was quite interested in certain GoLang projects until I dug deeper and two things stood out in particular to me and my requirements:
1. On Linux, code making syscalls needed (at the time I reviewed it - may have changed) to run a C-language co-process to call into the kernel. This aspect introduced some 'interesting' complexities and rather spoiled some of the GoLang promise (and performance - learned via 'crun' - the C-language alternative to 'runc').
2. In typical projects the source-code has an alarming number of "import "github/user/project" which relate to external dependencies fetched using "go get ..." so these external dependencies (and the graph of dependencies in a typical application-level project) have a similar security/review cycle issue.
Similar issue for point 2 in Rust Crates. Each Cargo.toml may well include lines of the form "some_external_library = { git = "https://github.com/SomeRandomAccount/SomeExternalLibrary" }"
Same applies to Perl with CPAN and others.
It seems to me there's a seesaw sliding-scale between Convenience and Trust and currently the scale is tipped too far in favour of Convenience.
Trust comes from reviewing the code - either yourself or your team, or by people you trust (typical web of trust). For example in Linux distributions we typically favour the package maintainers with implicit Trust when installed dependencies.
The problem, and challenge, for 'import the latest from $pseudo_random source' is the lack of a web of trust for each version/release/commit.