research!rsc: Defining Go Modules (Go and Versioning, Part 6)

I like almost everything about the design of vgo, except for the removal of what we call "vendoring" in the go tool.

I agree we don't need vendoring anymore for reproducibility. But I think vgo, and the go tool, should keep some form of "vendoring" for availability. For small teams, caching proxies are not a good solution, because it's another thing to maintain.

Would it be possible for vgo to maintain a "mirror" of downloaded modules in a project subdirectory, that we could commit? This directory would contain the .info, .mod and .zip files. It would have the same effect as a caching proxy, but without any additional infrastructure.

Yarn, a JavaScript package manager developed and used by Facebook, has an "offline mode" with an "offline mirror" that does something similar. Many Facebook teams commit and share their “offline mirror” in their monorepo, which means that most dependencies for new projects are often already checked into that folder, so the cost of storing the packages in source control gets lower the more projects use it. More info at https://yarnpkg.com/blog/2016/11/24/offline-mirror/.

This approach, without requiring a caching proxy per se, seems to work at scale (see Facebook), but also for small shops.

Anyway, thanks for the great work on vgo!

TOC for previous articles: https://research.swtch.com/vgo.

Links to previous discussions about articles in the series:

Part 1: https://news.ycombinator.com/item?id=16421966

Part 3: https://news.ycombinator.com/item?id=16431299

Part 4: https://news.ycombinator.com/item?id=16433425