Lightning Talk – Why Not To Have Bazel Dependencies
summary
Recommendation is to stop pushing transitive Bazel dependencies onto users and instead publish release archives with stable sha256 checksums and semantic versions. Practical moves include ship binaries for runtime deps (avoid forcing a 120 MB Go SDK by publishing ~5 MB cross-platform binaries), strip development-only load statements at packaging time, and sometimes vendor tiny thirdparty files when safe. Case studies: rules_nodejs publishes via npm to reduce transitive deps and rules_closure caused unexpected TensorFlow breakage when a stray load pulled in extra deps.
AI-written summary · about
chapters (9)
- 0:00Avoiding Bazel dependencies
- 1:06HTTP archives and Git issues
- 2:30Workspace complexity and transitive deps
- 4:14Dev vs runtime dependencies
- 5:57Third-party directory limits
- 6:39Reducing deps in rules_nodejs
- 8:46npm for Bazel rules
- 9:49Best practices for rules
- 10:32Future of Bazel deps
related talks
06mLightning Talk: Do You Love or Hate Your C++ Build System?
06mLightning talk from Andrey Sitnik
31mBazel: Do We Really Need Another Build Tool?
09mBazel: {Fast, Correct, Seamless}: Choose 3
42mSponsored Session: Dependencies: Do's and Don'ts
57mZen and the Art of Package Management
36mThe Role of Package Managers as Partners in License and Attribution Compliance
11mPerformant Bazel Builds for Web Monorepos at Scale