# Supported package ecosystems

> The package ecosystems inspect.software reads — nine registries with published-package facts, plus dependency manifests across all of them.


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](/wiki/ecosystem-adoption) and
[package maintenance](/wiki/package-maintenance).

## Registries read today

| Ecosystem | Registry | Adoption figure |
| --------- | -------- | --------------- |
| JavaScript / Node | npm | monthly downloads |
| Python | PyPI | monthly downloads |
| PHP | Packagist | monthly downloads |
| Rust | crates.io | monthly downloads |
| Ruby | RubyGems | lifetime total downloads |
| Elixir / Erlang | Hex | download figures |
| .NET | NuGet | lifetime total downloads |
| Go | Go module proxy | no public download counter |
| Java / JVM | Maven Central | no public package-download counter |

All nine registries contribute published-package facts — latest version,
publish recency, version history, deprecation state — to [package
maintenance](/wiki/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](/wiki/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](/wiki/ecosystem-adoption) ·
[package maintenance](/wiki/package-maintenance) ·
[methodology versions](/wiki/methodology-versions)