Golang Dependency Management — Doing it Right!

Leon Stigter
Dec 19, 2018 · 2 min read
Image for post
Image for post
Breaking free from vendoring chains (Picture by Pixabay)
  • Versioning: The app you create has a version and the dependency you rely on has one too, with vendoring it’s impossible to know which version of the dependency you have;
  • Repository size: If you store more data, your repositories will grow as well and those vendor folders can be huge. Also when you commit files their history will remain even if you delete them later on;
  • Local dependencies: With anything except the use of modules you cannot replace an existing dependency with a local dependency to test, for example, a new version;
  • Build time: Larger repos will take more time to clone and build, making it more time-consuming to push your latest update to production;
  • Repeatable builds: Without modules I can build my source against version 1.2 of a dependency and the next morning someone else in my team might build using version 1.3;
  • Immutable builds: If you depend on other software, you need that to be immutable and not changed by a developer that decides to experiment a little;
  • Project management: PRs for the project will list all changes in the vendor tree, making it difficult to perform proper validation of code.


Fearless updates from code to production

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store