You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/184.108.40.206 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.