Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/188.8.131.52 Safari/537.36
What did you expect to see?
In the docs for go mod vendor I expect to see something regarding vendoring a dependency for making changes. For example bug fixes or addressing vulnerabilities. However, in the docs it explicitly says "Local changes should not be made to vendored packages". I think it would be nice to include a quick mention of this usecase here and a link to the "replace" directive and/or "workspaces" to address this.
The text was updated successfully, but these errors were encountered:
The docs for go mod vendor are already too verbose; I'd rather not make them even more so. (We're trying to whittle down that verbose subcommand help text over time, but there's still a long way to go.)
In general I would expect users looking for “how to” content to start at https://go.dev/doc/ instead of the docs for individual go subcommands.
Once I have fully understood both possible approaches, and read the note that "replace directives are only applied in the main module" here, then I can finally make an informed decision on the approach I will take.
This seems a bit excessive when there could be a short blurb somewhere about "vendoring a module for bug/security fixes" that could link to these.
I am thinking of the case where a user wants to vendor some/all of their dependencies into a monorepo. If any edits need to be made to fix bugs, they can simply edit the module code directly. If a new version of the module is published and they wish to update, they will be required to resolve the merge conflicts.
A workspace can be used to achieve this although I am unsure if this is an intended usecase for them or not.