# Go vet "composite literal uses unkeyed fields" - Fix in CI

> Fix go vet "composite literal uses unkeyed fields" in CI - a struct literal lists values positionally and vet flags it as fragile. Use keyed fields.

Source: https://latchkey.dev/learn/go/go-vet-composite-literal-unkeyed-fields-in-ci  
Updated: 2026-06-26

go vet warns when a struct literal from another package omits field names. Positional literals break silently when the struct gains or reorders fields, so vet flags them - and CI that gates on vet fails.

## Diagnose it: toolchain, tags, or platform?

Go build failures that only appear in CI usually come from a different toolchain version, different build tags, or cross-compilation defaults that differ from your machine.

```Terminal
go version
go env GOOS GOARCH CGO_ENABLED GOFLAGS GOTOOLCHAIN

# build exactly what CI builds, verbosely
go build -v ./... 2>&1 | tail -40

# CGO is the usual difference: on by default locally, often off in a slim CI image
CGO_ENABLED=0 go build ./...
```

> A package that imports C fails only when `CGO_ENABLED=1`, and the default differs between environments and base images. Set it explicitly in CI rather than inheriting it.

## FAQ

### What causes Go vet "composite literal uses unkeyed fields"?

There are 2 common causes: positional literal of an imported struct and vet gated in ci. A struct from another package is initialized by position, so any field change silently shifts values.

### How do I fix Go vet "composite literal uses unkeyed fields"?

There are 2 fixes depending on which cause you have: use keyed fields and run vet locally before pushing. Work through them in order, since the first is the most common.

### What does Go vet "composite literal uses unkeyed fields" actually mean?

A vet or test run fails with composite literal uses unkeyed fields.

### How do I stop Go vet "composite literal uses unkeyed fields" happening again?

Always key struct literals of imported types. The prevention section lists 3 changes that keep it from recurring.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt