@f0x you're also not giving what amounts to commit access to your project to whoever wrote that code and the ever expanding circle of people they decide to trust themselves though

@nota that's what dependency versioning and lockfiles are for

@f0x lockfiles don't really change anything, they just mean you pull in the new code when you update your lockfile instead of when you install?

Unless you like, audit every single change your thousands of transitive dependencies have made.

@nota thousands is way overblown for most projects, but yeah, if it's security critical, you audit your dependencies. which tends to be a whole lot easier when they're all small as opposed to big kitchensink frameworks

@f0x I don't think that degree of auditing is feasible for almost anyone tbh. Especially not in fast moving ecosystems. So in practice you're just stuck with trust, which only works when the circle is relatively fixed and knowable.

I should say that I think this is a totally separate question from how the code is organized technically. You can totally have hundreds of tiny three function modules that are still just one entity of trust, with shared release management, security etc.

@f0x For example when I do say, audio stuff in rust, I might end up using a dozen crates, but they're all from the rust-audio project so I'm only adding a single entity to my circle of trust.

@nota yeah, that's pretty common in npm stuff too, 'dependency constellations'

@f0x I wonder if there's any tools to visualize this actually. As in, entity dependencies instead of module dependencies.