10 - Managing Dependencies: It Depends

This episode of the Bikeshed Podcast dives into dependency management, particularly within the context of front-end projects. The discussion centers around the "one version rule," a strategy adopted by companies like Wayfair to ensure consistency and reduce bundle sizes by using a single version of each library across all projects. The hosts explore the pros and cons of this approach, as well as alternative dependency management strategies.

Key Discussion Points:

• Introduction to Dependency Management: Dependency management involves pulling in libraries and managing updates, breaking changes, and inconsistencies across projects.
• The One Version Rule: The one version rule aims to ensure that only one version of each library is used across all projects within an organization. This reduces bundle sizes, avoids conflicts, and promotes consistency. React is used as an example, it typically functions as a singleton, using multiple versions is likely to cause issues.
• Benefits of the One Version Rule:
  • Smaller bundle sizes
  • Reduced conflicts between libraries
  • Increased consistency and shared knowledge across teams
  • Faster development and easier onboarding for new engineers
• Drawbacks of the One Version Rule:
  • Upgrading dependencies can become a large, complex project affecting multiple applications.
  • Managing breaking changes and coordinating upgrades can be challenging.
• Dependency Upgrade Challenges: Upgrades, especially breaking changes, require significant effort. Teams often postpone upgrades, leading to outdated dependencies and more complex upgrade processes later.
• HubSpot's Evergreen Dependency System: HubSpot uses an evergreen dependency system where non-breaking changes to libraries are automatically pulled down by all dependent projects on the next build. This reduces the burden of manual upgrades but requires robust tooling to test and verify changes.
• Trade-offs of Evergreen Dependencies:
  • Automatic upgrades can cause unexpected breakages if not properly tested.
  • HubSpot uses canary deployments and build tooling to mitigate these risks.
  • Build reproducibility becomes difficult as projects always pull the latest dependencies.
• Avoiding Breaking Changes: There's a growing trend towards avoiding breaking changes in internal libraries to minimize disruption and simplify upgrades.
• Peer Dependencies vs. Direct Dependencies: The hosts discuss the trade-offs between using peer dependencies (where the consumer provides the dependency) and direct dependencies (where the library includes the dependency).
• Airbnb's Dependency Management: Airbnb uses a system where applications and libraries don't have package.json files but instead use internal project.json files to enable or disable dependencies.
• Internal Tooling and Team Investment: The hosts emphasize the importance of internal tooling and dedicated platform teams to effectively manage dependencies and improve developer experience. Open-source tools can be useful for smaller teams, but larger organizations benefit from custom solutions.
• Building Important Systems by Committee: Building important systems like component libraries or design systems by committee can be challenging without a solid foundation and dedicated focus.
• The Tragedy of the Commons: Without a structured process or team to manage dependencies, it's unlikely that individuals will prioritize it, leading to a negative feedback loop of neglect and increasing complexity.

Sorry for not adding a nice graphic describing the library relationships - we'll leave that as an exercise to the listener!