lint can include Go files from nested modules without their go.mod

[shykes]

Description

Running the Go module linter through github.com/dagger/go fails for a module that contains a nested Go module.

Example from the Dagger repo:

dagger call -m github.com/dagger/go module --path=modules/doug lint

The failure is:

level=error msg="Running error: context loading failed: no go files to analyze: running `go mod tidy` may solve the problem"

But running golangci-lint directly on the host from modules/doug passes.

What seems to be happening

modules/doug contains a nested Go module at:

modules/doug/evals/go.mod

The Dagger Go lint pipeline builds a filtered source mount. For modules/doug, the include list contains:

modules/doug/**/*.go
modules/doug/go.mod
modules/doug/go.sum

This means the filtered source includes Go files from the nested module:

modules/doug/evals/*.go

but does not include the nested module boundary:

modules/doug/evals/go.mod

So inside the lint container, Go no longer sees modules/doug/evals as a separate module. It treats those files as part of the parent modules/doug module, which breaks package loading and causes the misleading golangci-lint error.

Expected behavior

The filtered source should preserve Go module boundaries.

Either:

modules/doug/evals/** should be excluded from the parent module lint source

or:

modules/doug/evals/go.mod should be included if modules/doug/evals/**/*.go is included

The current behavior includes nested module Go files but drops the nested module’s go.mod, which creates a filesystem shape that does not match normal Go module semantics.

Reproduction notes

A local filtered copy reproduces the issue:

1. Copy modules/doug parent Go files, go.mod, and go.sum.
2. Also copy modules/doug/evals/*.go.
3. Do not copy modules/doug/evals/go.mod.
4. Run golangci-lint run from modules/doug.

That produces the same failure. Adding modules/doug/evals/go.mod back makes the failure go away.