Proposal Details
Add official support for go mod init -modfile=<foo>.mod <module>.
In fact, it already works with Go 1.26.1, but the flag isn't documented:
$ go mod init -modfile=tools.mod github.com/dolmen-go/foo
go: creating new go.mod: module github.com/dolmen-go/foo
$ cat tools.mod
module github.com/dolmen-go/foo
go 1.26.1
$ go help mod init
usage: go mod init [module-path]
Init initializes and writes a new go.mod file in the current directory, in
effect creating a new module rooted at the current directory. The go.mod file
must not already exist.
Init accepts one optional argument, the module path for the new module. If the
module path argument is omitted, init will attempt to infer the module path
using import comments in .go files and the current directory (if in GOPATH).
See https://golang.org/ref/mod#go-mod-init for more about 'go mod init'.
Note: the information message says creating new go.mod, not creating tools.mod, which is a bug (see fix in CL 761781).
So this proposal is about official support through documentation (also test coverage).
Source:
|
// ModFilePath returns the path that would be used for the go.mod |
Why?
- Ease creation of alternate compliant
go.mod files.
- Be consistent with the availability of
-modfile in other go mod commands.
Use case
Create a separate go.mod for maintainer tools (as go tool supports -modfile) so tools can rely on a more recent version of the Go toolchain or some heavy dependencies, but not force this to downstream users of the module:
$ go mod init github.com/dolmen-go/foo
go: creating new go.mod: module github.com/dolmen-go/foo
$ go get go@1.24.0
go: downgraded go 1.26.1 => 1.24.0
$ go mod init -modfile=tools.mod $(go list -m)
go: creating new go.mod: module github.com/dolmen-go/foo
$ go get -modfile=tools.mod -tool golang.org/x/tools/cmd/goimports@master
go: added golang.org/x/mod v0.34.0
go: added golang.org/x/sync v0.20.0
go: added golang.org/x/sys v0.42.0
go: added golang.org/x/telemetry v0.0.0-20260311193753-579e4da9a98c
go: added golang.org/x/tools v0.43.1-0.20260401182238-b20ccfda7c4e
$ go tool -modfile=tools.mod goimports -h 2>&1 | head -1
usage: goimports [flags] [path ...]
$ cat go.mod
module github.com/dolmen-go/foo
go 1.24.0
$ cat tools.mod
module github.com/dolmen-go/foo
go 1.26.1
tool golang.org/x/tools/cmd/goimports
require (
golang.org/x/mod v0.34.0 // indirect
golang.org/x/sync v0.20.0 // indirect
golang.org/x/sys v0.42.0 // indirect
golang.org/x/telemetry v0.0.0-20260311193753-579e4da9a98c // indirect
golang.org/x/tools v0.43.1-0.20260401182238-b20ccfda7c4e // indirect
)
Proposal Details
Add official support for
go mod init -modfile=<foo>.mod <module>.In fact, it already works with Go 1.26.1, but the flag isn't documented:
Note: the information message says
creating new go.mod, notcreating tools.mod, which is a bug (see fix in CL 761781).So this proposal is about official support through documentation (also test coverage).
Source:
go/src/cmd/go/internal/modload/init.go
Line 720 in affadc7
Why?
go.modfiles.-modfilein othergo modcommands.Use case
Create a separate go.mod for maintainer tools (as
go toolsupports-modfile) so tools can rely on a more recent version of the Go toolchain or some heavy dependencies, but not force this to downstream users of the module: