Supported package ecosystems

A repository is more than its GitHub presence: most reusable software ships through a package registry, and the registry holds adoption and maintenance evidence GitHub cannot show — real download volume, publish recency, deprecation state. inspect.software resolves the packages a repository publishes and folds registry data into two metrics: ecosystem adoption and package maintenance.

Registries read today

All nine registries contribute published-package facts — latest version, publish recency, version history, deprecation state — to package maintenance. Where a registry publishes no monthly download figure (RubyGems, NuGet), the adoption metric falls back to lifetime total downloads — whichever figure the registry actually provides, so no ecosystem is structurally disadvantaged. The Go module proxy and Maven Central publish no download statistics of any kind. For Go this leaves maintenance evidence as the only signal; for Maven Central the dependent-project count published by deps.dev supplies a comparable adoption measure.

NuGet is incrementally discovered from its official catalog feed. Its public search metadata supplies lifetime total downloads, which are used for the catalogue threshold. Maven Central is incrementally discovered from the official Maven Central Indexer. Central publishes no package download counter, so eligibility instead relies on the deps.dev dependent-project count together with a declared GitHub source; packages meeting the dependents threshold are auto-queued like other ecosystems.

Go module discovery

The catalogue worker also reads the official public Go Module Index to find new stable releases. The index publishes a module path, version, and timestamp but no download/adoption counter. Automatic Go candidates therefore need a direct github.com/owner/repo module path and a stable release published within the last 730 days; they are ranked by release freshness, not by invented download figures. The normal low-priority catalogue queue and scan still verify the repository before it appears in the public record.

Declared dependencies

Independently of publishing, the inspection parses dependency manifests across ecosystems — npm, PyPI, Packagist, crates.io, Go, Maven, RubyGems, NuGet, and Hex — and records the declared direct dependency list in every report. Resolving those dependencies against registries and vulnerability databases (freshness, known CVEs) is on the published methodology roadmap.

All dependencies

Alongside the direct list, the inspection records the repository's full resolved dependency set — direct plus indirect (transitive) — from GitHub's dependency graph, which covers the transitive closure whenever the repository commits a lockfile. The report states direct and indirect counts separately and names the source of the resolved set. This collection is best-effort: when the dependency graph is unavailable, the report says so explicitly and every other part of the inspection proceeds unaffected.

Repositories that publish no package

Applications, infrastructure repositories, and documentation projects often publish nothing to any registry. For them the two registry-backed metrics are null: excluded from their categories with weights renormalized, never counted as zero. A non-publishing repository is measured purely on its other evidence — see the health index for the missing-data rules.

Package-to-repository matching

A package only contributes to a repository's report when the registry entry verifiably points back to that repository. A package that claims a different source repository is listed in the report but flagged and left out of the computation — preventing adoption figures from being borrowed or spoofed.

Multi-ecosystem, multi-language repositories

One codebase can legitimately live in several ecosystems at once — a Rust core with Python bindings and an npm wrapper publishes to crates.io, PyPI, and npm from a single repository. Scoring already treats this soundly: download counts are summed across every verified package. Wherever the public record lists a repository's ecosystems — catalogue cards, filters, report chips — the order reflects evidence strength, not the alphabet: ecosystems with verified published packages come first, ranked by download volume; ecosystems seen only in dependency manifests follow. A package that points at a different source repository never leads the list.

Languages follow the same discipline. The languages shown for a repository are those holding at least 10% of its code by volume, largest first — so CI scripts and generated markup do not masquerade as a project language, and a genuinely bilingual codebase is presented as one. Catalogue cards show up to three ecosystems and three languages per repository.

Related: ecosystem adoption · package maintenance · methodology versions