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

  1. Re-run with -mod=mod or -mod=readonly to consult the complete module graph.
  2. Add the dependency (`go get <path>` then `go mod vendor`) so it becomes resolvable.
  3. 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

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


AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/be9d09f2c9d6a260. Report an issue: GitHub.