Go "internal error: package without types was imported" - Fix in CI
This internal compiler error means Go tried to use a package whose type information was missing - almost always a corrupted or mismatched build cache rather than a fault in your code.
What this error means
A build fails with internal error: package "X" without types was imported from "Y". It often surfaces after a toolchain change, a shared cache between Go versions, or a partially populated build cache.
go
internal error: package "github.com/foo/bar" without types was imported from "example.com/app"Common causes
Stale or mixed build cache
A build cache populated by one Go version is reused by another, leaving type info inconsistent.
Corrupted cache entry
A partially written cache entry has package data but no type export, tripping the internal check.
How to fix it
Clean the build cache and rebuild
- Clear the Go build cache so the package is recompiled from scratch.
Terminal
go clean -cache
go build ./...Key the cache on the Go version
- Include the Go version in the build-cache key so different toolchains never share a cache.
.github/workflows/ci.yml
- uses: actions/cache@v4
with:
path: ~/.cache/go-build
key: go-build-${{ runner.os }}-${{ env.GO_VERSION }}-${{ hashFiles('**/go.sum') }}How to prevent it
- Key the build cache on the Go version so toolchains never share it.
- Run
go clean -cachewhen switching Go versions locally. - Pin a single Go version per job.
Related guides
Go "package command-line-arguments is not a main package" - Fix in CIFix Go "package command-line-arguments is not a main package" in CI - go build/run got file paths that are no…
Go "import cycle not allowed" - Fix in CIFix Go "import cycle not allowed" in CI - two or more packages import each other directly or transitively. Br…
Go "undefined: runtime.X" from a Go version mismatch - Fix in CIFix Go "undefined: runtime.X" in CI - code uses a runtime symbol from a newer Go than CI runs. Install a matc…