Package matching
How we resolve a package name to a GitHub repository — and what happens when we can't.
For each package in your lockfile we follow a deterministic lookup path to find the GitHub repo that publishes it. The path varies by ecosystem (see Supported formats for the per-ecosystem registry hop), but the shape is the same: parse → registry lookup → extract the repository URL → confirm it's a public GitHub repo.
When a match works #
Most popular packages publish a repository URL in their registry metadata
that points at GitHub. When that URL is present, the match is one-shot and
the resolved source becomes a tracked source automatically.
When a match fails #
A package can fail to match for several reasons:
- No repository field in the registry metadata. Maintainer just didn't set it.
- Non-GitHub host. Sources hosted on GitLab, Bitbucket, Codeberg, or internal registries are not yet supported. Public GitHub mirrors do work if the package metadata points at them.
- Renamed or unpublished package. The registry returns 404.
When a package can't be matched, it shows up in the upload result summary as "unmatched" — no failure, just an honest "we couldn't find a public GitHub repo for this." You can come back later and add the source manually if you find the URL another way.
Transitive dependencies #
Lockfiles include transitive dependencies (the dependencies of your dependencies), and we match all of them. This is the point — the risky release is rarely the library you remember installing; it's something five hops down.
On the Hobbyist tier you pick up to 10 packages to track from the lockfile. A good rule: pick the high-traffic ones at the top of your dependency tree plus any libraries with a history of breaking changes. Re-evaluate as the project grows.