Go version

go1.24.2

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE='auto'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/xxx/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/xxx/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/9t/839s3jmj73bcgyp5x_xh3gw00000gn/T/go-build2973783802=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/xxxx/20250428/tools/gopls/go.mod'
GOMODCACHE='/Users/xxx/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/xxx/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn,direct'
GOROOT='/usr/local/go'
GOSUMDB='off'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/xxx/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

In many repositories that use the multi-module pattern (often monorepos), if there is a go.mod file in one directory, the Go files in a subdirectory that also contains a go.mod file will not be processed.

This organizational structure may violate the best practices of multi-module setups, but I have found that such situations are prevalent in many open-source projects.

For example, for the following organizational structure and code: 

➜  tmp20250509 tree -f
.
├── ./diff.go
├── ./go.mod
├── ./go.sum
└── ./utils
    ├── ./utils/go.mod
    └── ./utils/utils.go

2 directories, 5 files
➜  tmp20250509 cat diff.go       
package main

func main() {
    Diff()
}

func Diff() {

    toPaths := map[string]string{
        "diff1": "11111",
        "diff2": "22222",
    }

    paths := make(map[string]string)
    for key, value := range toPaths {
        paths[key] = value
    }

}
➜  tmp20250509 cat utils/utils.go 
package utilssss

func Demo() {

    toPaths := map[string]string{
        "1": "one",
        "2": "two",
    }

    paths := make(map[string]string)
    for key, value := range toPaths {
        paths[key] = value
    }

What did you see happen?

After executing modernize -fix -test ./...

➜  tmp20250509 modernize  -fix -test ./... 
➜  tmp20250509 
➜  tmp20250509 
➜  tmp20250509 cat diff.go       
package main

import "maps"

func main() {
    Diff()
}

func Diff() {

    toPaths := map[string]string{
        "diff1": "11111",
        "diff2": "22222",
    }

    paths := make(map[string]string)
    maps.Copy(paths, toPaths)

}
➜  tmp20250509 
➜  tmp20250509 cat utils/utils.go
package utilssss

func Demo() {

    toPaths := map[string]string{
        "1": "one",
        "2": "two",
    }

    paths := make(map[string]string)
    for key, value := range toPaths {
        paths[key] = value
    }

}

The diff.go file has changed as expected, while utils/utils.go has not changed.

What did you expect to see?

I'm not sure if this is expected behavior or a bug. However, I think that since ./... is explicitly specified, it should process the Go files in the current directory and all its subdirectories. Otherwise, this situation would lead to inconsistencies in style within the same repository.

Comment From: gabyhelp

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: matloob

In Go 1.25+ the 'work' package pattern can be used instead. (It expands to all the packages in modules included in a workspace).

Comment From: cuishuang

In Go 1.25+ the 'work' package pattern can be used instead. (It expands to all the packages in modules included in a workspace).

Thank you for your reply.

I also want to know whether the current mode of ./... meets expectations for stock projects and codes.

Comment From: findleyr

Hi, is this reproducible if you use a go.work file that uses all of your modules? That is required for linking modules into a single build, and declaring your intent to use them in your workspace.

(you can also test this with go list, to see which packages are included in the ./... pattern).