Dependencies Belong in Version Control
Whether third-party dependencies should be checked into version control or fetched at build time is fiercely contested here. Proponents of vendoring everything – including libraries, assets, and even toolchains – argue it’s the only reliable way to ensure long-term, reproducible builds and to avoid breakages from disappearing servers or shifting ecosystems. Critics counter that this bloats repositories, complicates security updates, and duplicates what package managers, artifact repositories, containers, and systems like Nix are designed to handle, framing the real challenge as choosing the right level of reproducibility versus maintainability for each project.
Role of Package Managers vs VCS
- One camp argues dependencies should be installed via real package managers before the build, not committed, to avoid bloated repos and rely on lockfiles and internal artifact repos instead.
- Others say package managers alone aren’t enough for long‑term reproducibility: if upstream servers disappear or change, old projects can become unbuildable.
- Some suggest a middle ground: commit lockfiles, use internal mirrors/caches or artifact repos, and only vendor when necessary (air‑gapped, patched deps, etc.).
Reproducibility & Longevity
- Pro‑VCS side: checking in dependencies ensures builds still work years later, independent of external networks and package hosts that may die, mutate, or drop old versions.
- Critics counter that you don’t need gigabytes of binaries in VCS; pinning by hash and archiving artifacts elsewhere (e.g., artifact repo, container images, VM snapshots) is sufficient.
- There’s debate over how far to go: just direct deps, or also toolchains, OS libs, even whole OS images/VMs. Several note you must pick a “stable interface” boundary (language, ABI, libc, etc.).
Security & Updates
- Vendoring can protect against unpinned transitive deps suddenly pulling in malicious or broken versions (e.g., node‑ipc incident).
- Opponents argue manual vendoring scales poorly: updating dozens of checked‑in deps for CVEs is more work than centralized package updates plus automation; risk of staying outdated is high.
- Lockfiles and auto‑update tooling are seen as critical regardless of approach.
Tooling & Ecosystem Differences
- Rust/Cargo, Maven, modern JS tooling, vcpkg, Nix/Guix, and Docker are all cited as different takes on reproducible environments, with mixed reviews.
- Some say Nix/functional package management “solves this”, others say it complicates life.
- Git is widely seen as poor for large binary blobs; suggestions include Git LFS‑like systems with deduplication and P2P/torrent distribution.
Performance, DX, and Repo Size
- Concerns about huge repos (multi‑GB, many blobs) hurting Git performance and developer onboarding.
- Submodules are proposed by some as the “right” way to keep dependencies in VCS, but others report them as a major source of pain.
- IDEs, linters, virtualenvs, and cloud dev environments often assume standard package‑manager workflows, making ad‑hoc vendoring harder to integrate.