golang/go · warning
can't resolve module using the vendor directory (Use -mod=m
Error message
can't resolve module using the vendor directory (Use -mod=mod or -mod=readonly to bypass.)
What it means
In `-mod=vendor` mode the module graph is intentionally incomplete: only vendored modules are visible. When a listed module path resolves to version "none" (absent), the go command cannot tell whether it is a real but un-vendored dependency, so it reports this per-module Error and points you at mod/readonly to query the full graph.
Source
Thrown at src/cmd/go/internal/modload/list.go:269
// is no such root we should have loaded a non-nil mg.
panic(fmt.Sprintf("internal error: root requirement expected but not found for %v", arg))
}
} else {
v = mg.Selected(arg)
}
if v == "none" && mgErr != nil {
// mgErr is already set, so just skip this module.
continue
}
if v != "none" {
mods = append(mods, moduleInfo(ld, ctx, rs, module.Version{Path: arg, Version: v}, mode, reuse))
} else if cfg.BuildMod == "vendor" {
// In vendor mode, we can't determine whether a missing module is “a
// known dependency” because the module graph is incomplete.
// Give a more explicit error message.
mods = append(mods, &modinfo.ModulePublic{
Path: arg,
Error: modinfoError(arg, "", errors.New("can't resolve module using the vendor directory\n\t(Use -mod=mod or -mod=readonly to bypass.)")),
})
} else if mode&ListVersions != 0 {
// Don't make the user provide an explicit '@latest' when they're
// explicitly asking what the available versions are. Instead, return a
// module with version "none", to which we can add the requested list.
mods = append(mods, &modinfo.ModulePublic{Path: arg})
} else {
mods = append(mods, &modinfo.ModulePublic{
Path: arg,
Error: modinfoError(arg, "", errors.New("not a known dependency")),
})
}
continue
}
var matches []module.Version
for _, m := range mg.BuildList() {
if match(m.Path) {View on GitHub (pinned to b6b368adc5)
Solutions
- Re-run with -mod=mod or -mod=readonly to consult the complete module graph.
- Add the dependency (`go get <path>` then `go mod vendor`) so it becomes resolvable.
- Verify the module path spelling against go.mod / vendor/modules.txt.
Example fix
# before $ go list -m example.com/newdep # -mod=vendor in effect # module example.com/newdep ... Error: can't resolve module using the vendor directory # after $ go list -mod=readonly -m example.com/newdep
Defensive patterns
Strategy: validation
Validate before calling
// Before resolving a possibly-un-vendored module, check vendor/modules.txt.
func isVendored(modPath string) bool {
b, err := os.ReadFile("vendor/modules.txt")
if err != nil { return false }
return bytes.Contains(b, []byte("# "+modPath+" "))
} Type guard
null
Try / catch
null
Prevention
- For dependency queries under vendor mode, switch to -mod=readonly.
- Run `go mod vendor` after adding any dependency used in vendored builds.
- Don't rely on `go list -m <path>` to discover new deps while vendored.
When it happens
Trigger: `go list -m <path>` (or any module-listing command) with cfg.BuildMode==vendor where <path> is not present in the vendor/modules.txt or the build list.
Common situations: Querying a candidate dependency while vendored; checking whether something is a dependency before vendoring it; typos in the path.
Related errors
- not a known dependency
- cannot run go list: %v %s
- without -mod=vendor, directory %s has no package path
- use of vendored package not allowed
- cannot find package
AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12).
Data as JSON: /api/errors/be9d09f2c9d6a260.
Report an issue: GitHub.