[TobyTheDog123]

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency.

While it's ridiculous to expect that people will audit every single dependency and sub-dependency, it's not ridiculous to expect tooling to do the same.

Packages should be given an overall quality rating (and honestly it might be great for an ecosystem as large, diverse, and welcoming-to-beginners as JS/TS), part of the score comes from the number of different dependencies/sub-dependencies -- a social package score if you will. If a package causes the dependency graph to explode, give a warning before installing it.

Then, if you're NPM, you don't need all of these convoluted and exploitable policies around un-publishing.

[matheusmoreira]

> While it's ridiculous to expect that people will audit every single dependency and sub-dependency

It's not ridiculous at all. Professional programmers should answer for the dependencies they bring into their projects.

[aaomidi]

This is why I prefer vendoring dependencies. I have to actually code review them.

[cxr]

Whether you're storing your own copy of a given dependency and whether you've done code review for it are orthogonal concepts. (You can check it in and perform the same amount of review that people do when deferring to `npm install` for late fetching, i.e. none.)

Conflating these two not-unrelated-but-still-distinct concepts is a big contributor to why the current state of the art is so fraught.

[mcny]

I'd be called insane if I suggested it. I work with dotnet and I'd rather not add all the code in newtonsoft json and manually review each line. I mean where does it stop? Why not have everyone in the world code review asp.net and dot net libraries for every single website project at that rate?

[sakjur]

Rust’s Cargo vet offers an answer to that question.

You can import a list of audits from trusted auditors, which should cover all popular packages. Now you have to audit dependencies that aren’t well-known in the community, which really is the set of dependencies that you should take an extra look at. The big popular JSON libraries can be audited by either Microsoft or some of the other large projects that are using them.

You’d explicitly share your trust list in your audit file, and anything (updates or new packages) that isn’t trusted by you or one of your listed auditors is flagged for auditing.

https://mozilla.github.io/cargo-vet/index.html