go-version-file does not parse .mod files other than go.mod

[kaovilai]

Description

When using go-version-file with a .mod file that is not literally named go.mod (e.g., golangci-lint.mod, tools.mod), the parseGoVersionFile function fails to extract the Go version correctly.

This is because the current implementation checks path.basename(versionFilePath) === 'go.mod', which only matches files named exactly go.mod. Any other .mod file falls through to the default case, which returns the entire file contents as the version string — causing version resolution to fail.

Use Case

A common Go community pattern is to use dedicated module files for tool dependencies. For example, golangci-lint recommends using a separate golangci-lint.mod file to pin the linter version independently from the project's go.mod.

Users should be able to use these files with go-version-file to install the correct Go version:

- uses: actions/setup-go@v6
  with:
    go-version-file: golangci-lint.mod

Current Behavior

parseGoVersionFile only recognizes:

• go.mod (exact basename match)
• go.work (exact basename match)
• .tool-versions (exact basename match)

Any .mod file with a different name (e.g., golangci-lint.mod, tools.mod) is not parsed as a Go module file.

Expected Behavior

Any file ending in .mod should be parsed using the same Go module file logic (extracting toolchain or go directives), not just files named exactly go.mod.

Proposed Fix

Change the condition from:

path.basename(versionFilePath) === 'go.mod'

to:

versionFilePath.endsWith('.mod')

Note

Responses generated with Claude

[mahabaleshwars]

Hi @kaovilai,
Thank you for creating this feature request. We will investigate it and provide feedback as soon as we have some updates.