TL;DR: Upgrade grype to a release that supports the lockfile format - the parser lags behind package manager releases. If you cannot upgrade, regenerate the lockfile with an older lockfile version the installed grype understands, or convert it. Check grype's supported-ecosystem list before assuming the file is corrupt.

```text
unable to parse lockfile: unsupported package manager version
```

1. Identify the lockfile version: open the lockfile header and note the version field. Expected: you see a version newer than what your grype supports.
2. Check your grype version against its supported lockfile versions. Expected: you confirm the gap - grype is behind the package manager.
3. Upgrade grype to the latest release and re-run. Expected: the lockfile parses and the scan proceeds.
4. If upgrading is blocked, regenerate the lockfile pinned to the older format your grype supports. Expected: grype parses the regenerated file.
5. As a stopgap, convert the lockfile to an SBOM with a compatible tool and scan the SBOM instead. Expected: coverage without waiting on the upgrade.

## Use this when
- grype cannot parse a lockfile
- the package manager is newer than grype
- lockfile version errors appear right after a toolchain upgrade
- the lockfile itself opens fine in the package manager

## Not for this skill when
- the lockfile is corrupt or truncated
- grype parses it but reports no packages
- the issue is a different parser error
- the package manager itself cannot read the file

## Variant phrasings
- grype unsupported lockfile version
- grype unable to parse lockfile
- grype lockfile format not supported
- grype package manager version not supported

## Why it happens
Package managers periodically bump their lockfile format. Grype's parsers are written per format version, so a lockfile from a newer release hits the "unsupported version" guard until grype ships an updated parser - the file is fine, the reader is just old.

## Edge cases
- some package managers write a forward-compatible version marker but old content - the version field is what grype checks
- monorepos mixing lockfile versions need per-directory scans with the right grype
- upgrading grype can change the vulnerability database schema too - update both together
- lockfiles generated with experimental flags may carry a version grype will never support - regenerate without the flag

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QHC0_P6tMVKF6XrYwYh63A