A critique of package managers

Here's a summary of the themes expressed in the Hacker News discussion, with direct quotations:

The Problem of "Dependency Hell"

A central theme is the acknowledgment of "dependency hell," a situation where managing a large number of software dependencies becomes overwhelmingly complex and problematic. Users describe this as a common experience in large projects, leading to difficulties in understanding, debugging, and maintaining code.

• spacebanana7 eloquently captures frustration with this: "Projects having thousands, if not tens of thousands, of dependencies where you don’t know if they work properly, where are the bugs, you don’t how anything is being handled—it’s awful."
• pmarreck also touches upon its pervasive nature: "But eventually, the cancer will overtake the project if it keeps growing. Source: Have worked on a million-LOC Ruby app"

Automation vs. Manual Management of Dependencies

The discussion heavily debates whether automating dependency management, through tools like package managers, is beneficial or detrimental. Some argue that automation, by obscuring the complexity, can lead to more and worse dependencies, while others contend that manual management is impractical and inefficient.

• spacebanana7 expresses a strong opinion against automating this specific problem: "This the wrong thing to automate. You can do this manually, however it doesn’t stop you getting into hell, rather just slow you down, as you can put yourself into hell (in fact everyone puts themselves into hell voluntarily). The point is it makes you think how you get there, so if you have to download manually, you will start thinking “maybe I don’t want this” or “maybe I can do this instead”. And when you need to update packages, being manual forces you to be very careful."
• Countering this, smw highlights the practical burden of manual dependency management: "Exactly! Who has the time or the discipline to do that manually?"
• Sesse__ questions the effectiveness of making dependency addition painful: "You don't think making adding dependencies incredibly slow and painful would make people have fewer of them?"
• 1GZ0 interprets the author's stance as a lesson learned: "He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams 'I've been down the package manager route and paid the price'. Not inexperience."

The Role and Efficacy of Package Managers

Package managers like npm, yarn, and pnpm are at the heart of the debate. Participants discuss their benefits, drawbacks, and the underlying issues they attempt to address.

• Octoth0rpe highlights the fundamental need for tools that help manage updates: "I mean, sure. So what does the solution look like? From my perspective it looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager."
• zdragnar explains the evolution of package managers like yarn and pnpm as responses to npm's previous shortcomings: "Yeah, yarn and co came about because npm was slow, buggy and didn't honor its own lockfile."
• bluGill points out the difficulties even with package managers: "Often the update isn't source compatible with the package that uses it so you can't update. There are some projects I use that I can't update because I use 6 different plugins, and each updates to the main project on a different schedule on their own terms... Sometimes a package is hijacked (see xv) and so you really should be doing an audit of every update you apply."
• bluGill also emphasizes the importance of control over package sources: "The other thing is your package manager cannot go out to the internet randomly. You need it to download from a place you are comfortable with... If you are a company project that means an internal server/mirror because otherwise something you depend on will disappear in the future."

The Nature of Dependencies and Project Design

Several users discuss the fundamental decision-making process regarding dependencies, suggesting that a more critical approach to "left-pad"-type libraries is warranted.

• Sesse__ advocates for a simpler philosophy: "Obviously taking on fewer such liabilities?"
• smw uses Go as an example of a language with a strong standard library, implying fewer external dependencies are needed: "When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done."
• smw's example is immediately challenged by kunley, who defends the author's perspective: "Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience."
• kunley then clarifies that the author's argument isn't against dependencies entirely, but for careful selection: "Actually his perspective is quite reasonable. Go is in the other part of the spectrum than languages encouraging 'left-pad'-type of libraries, and this is a good thing."

Trust and Liability in Third-Party Code

A recurring concern is the inherent risk and potential liability associated with using third-party code, regardless of how it's managed.

• Octoth0rpe succinctly states: "Each dependency is a potential liability."
• bluGill reiterates this by mentioning license changes and package hijacking as reasons for audits: "Sometimes a package will change license and you need to check the legalese before you update. Sometimes a package is hijacked (see xv) and so you really should be doing an audit of every update you apply."

Parallels to Other Software

The discussion extends to consider if the arguments against package managers apply equally to other complex software systems, like operating systems.

• benmmurphy draws a parallel: "Not sure why this argument doesn't also apply to operating systems. Maybe everyone should be writing all their programs to run on a custom micro-kernel. Surely we can't trust other programmers to write something as complicated as an operating system."