cmd/go: Docs for `go mod vendor` does not include any information about vendoring a module for making changes

[iastewar]

What is the URL of the page with the issue?

https://go.dev/ref/mod#go-mod-vendor

What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

Screenshot

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.

[bcmills]

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.

[iastewar]

Thanks for the explanation! It makes sense to shorten the help text.

To find the information I need from the main docs page, I need to:

1. Find and click on Module release and versioning workflow
2. Read "Coding against an unpublished module".

AND
Read https://go.dev/doc/tutorial/workspaces

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.

Maybe I'm missing something here?

[seankhliao]

Vendoring for bug fixes is almost always the wrong solution as it bypasses all of go's dependency management. It shouldn't be a serious option.

Workspaces are local only, they shouldn't factor in to this.

[iastewar]

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.