What does it mean to 'vendor' a dependency into a repository, and why might a team choose to do that instead of pulling it from a package registry at build time?

## What vendoring is **Vendoring** is the act of copying a dependency's code — either its source or a built artifact — directly into your own repository so it is versioned alongside your application code, rather than being fetched dynamically from an external package registry (npm, Maven Central, PyPI, crates.io) every time someone builds or installs the project. The word comes from 'vendor,' in the sense of 'the vendor's code now lives inside our tree.' Mechanically it can mean several things depending on ecosystem: - **Go** had a first-class `vendor/` directory convention where `go mod vendor` would populate a folder with the exact source of every transitive dependency. - Some **npm** shops commit `node_modules` wholesale. - **C/C++** projects without a mature package manager often literally copy a library's `.c/.h` files into a `third_party/` folder. - Some organizations vendor by **re-publishing** a dependency to an internal artifact repository (Artifactory, Nexus) under their own coordinates, a lighter-weight variant of the same idea. ## The problem it solves The problem vendoring solves is **build-time uncertainty**. A normal dependency resolution step reaches out over the network to a registry, downloads a package, and trusts that the artifact you get today is the same one you'll get in a year. That trust can break concretely: - the registry can have an outage during a critical deploy window; - a maintainer can unpublish or 'yank' a version (the 2016 **left-pad** incident broke thousands of JavaScript builds when an 11-line npm package was pulled); - a version can be silently overwritten or compromised in a **supply-chain attack**; - or you may be building in an **air-gapped** environment (defense, some finance, some industrial systems) with no route to the public internet at all. Vendoring converts 'fetch this dependency' into 'read this file that is already sitting in the checkout,' making the build **hermetic** — it needs nothing outside the repository to reproduce byte-for-byte, valuable both for reliability and for deterministic-build supply-chain-security tooling (e.g., SLSA provenance). ## The trade-off The trade-off shows up in three places. 1. **First, repository size and diff noise:** vendoring a dependency tree can add tens or hundreds of megabytes to a repo, slow clones, and produce enormous, unreviewable diffs when a vendored library is upgraded (a `node_modules` bump can touch tens of thousands of lines no human will actually read). 2. **Second, and more dangerous, is the patching burden:** once a library's code lives in your tree, nothing automatically tells you when a CVE is published against the upstream original — normal dependency-scanning tools (Dependabot, Snyk, `npm audit`) key off registry metadata and package manifests, and a vendored copy with hand-edited or renamed files can silently fall off that radar. Teams that vendor need a separate, disciplined process to track 'what upstream version is this based on' and to re-pull security fixes. 3. **Third, there's a subtler correctness risk:** if someone patches the vendored copy directly without recording what changed and why, the codebase accumulates undocumented forks that are hard to reconcile on the next vendor refresh, and easy to lose entirely. ## When teams reach for it In practice, most teams use vendoring selectively rather than wholesale. A common pattern is to vendor a small number of dependencies that are either: - **extremely stability-critical** (a cryptography primitive you don't want silently swapped underneath you), - **unmaintained-but-needed** (the upstream project is dead, so you fork and vendor it), - or subject to a **licensing/audit requirement** mandating exact code review of everything that ships. Go's ecosystem leaned into vendoring more broadly for years because its module system historically had weaker guarantees than Maven's coordinate + checksum model, so `vendor/` plus a `go.sum` checksum file gave both hermetic builds and integrity verification in one step. Regulated financial and government software shops frequently vendor everything that ends up in a shipped binary, specifically so a security audit can walk the actual bytes that will run in production without trusting a live registry at audit time. ## The alternative most teams pick instead The alternative most teams reach for instead of full vendoring is a **lockfile** (`package-lock.json`, Gradle/Maven with pinned versions plus checksum verification, `Cargo.lock`) combined with a **private artifact-caching proxy** (Artifactory, Verdaccio, Sonatype Nexus) that mirrors upstream packages once and serves them internally forever after. This captures most of vendoring's reliability and reproducibility benefits — a pinned, checksum-verified, always-available artifact — without the repo bloat or the loss of automated vulnerability scanning, which is why it has become the more common default; vendoring is reserved for the specific cases above where its extra guarantees are worth the extra weight.