For me, personally, my "hatred" developed while working on a team that shipped software living in other people's process spaces. Classical examples of this are

For me, personally, my "hatred" developed while working on a team that shipped software living in other people's process spaces. Classical examples of this are metrics clients, tracing clients, loggers, HTTP frameworks, routers, etc. Tools that are hard/impossible to spin out into a dedicated microservice but generic enough to warrant trying to share that code across many services. These dependencies can have measurable impact on the user experience. Some teams just toss the code over the wall so "it's someone else's problem." But I'd take a "every instance of my code in a production server is a production deployment" approach. Being able to test your changes against real production traffic, knowing when you've made a change that is going to break services, owning that, being able to roll it back yourself. All of that is stuff I want in my dependency manager. A dependency is more than something down inside a node_modules directory. It's a code path that executes alongside, or even directly handles incoming customer requests. Trying to track down and upgrade my library/framework/w.e. when it's deployed across 100,000+ instances for 10,000+ services is... not fun. Even less fun is trying to surgically update _only_ my code and not rebuild the entire world pulling in a huge pile of changes along with my changes. Package management failed me when I tried to model deployments as a collection of stakeholders shipping code to production. This isn't just an npm problem. This sucks in pretty much every package manager I've worked with. Don't get me started on apt... unpack an ar archive into a global namespace, run some Rube Goldberg scripts, and hope for the best. The Nix paper gives me hope, but I never got around to using Nix in production before I moved on from large-scale deployments.