When a customer's lead maintainer, package owner, release engineer, or open-source-program-office representative publishes an npm package to the npm public registry, a Python distribution to the Python Package Index (PyPI), a Java artifact to Maven Central, a Rust crate to crates.io, a Ruby gem to RubyGems.org, a Go module to the public Go module proxy, a .NET package to NuGet.org, or a container image annotation to a public registry that participates in the SLSA provenance chain — and declares your product as a runtime dependency under dependencies, a peer dependency under peerDependencies, a build-time toolchain requirement under devDependencies or build-system.requires, a transitive-resolution anchor in the lockfile, or a platform-of-record citation in the README metadata that ships with every install artifact — they are delivering a category of endorsement that no marketing-elicited testimonial can replicate. The declaration has been prepared under the release-engineering scrutiny of a package maintainer who carries downstream-breakage accountability when the dependency edge breaks, attested by the customer's release-approval chain through the same publish workflow that gates every package release, archived in the immutable package-registry record where every version is content-addressed and every metadata revision is preserved, and operationally load-bearing in that the declared dependency edge is resolved into the build of every downstream consumer that installs the package. The dependencies field carries the customer's runtime-binding endorsement, the README metadata carries the platform-of-record endorsement, and the surrounding release-engineering context establishes that the endorsement was issued under the most release-pressured open-source-publication environment any software-producing organization operates.
Almost no B2B developer-tools, infrastructure, observability, security, or platform-engineering marketing team systematically extracts product mentions from public package-registry archives. The omission is the natural extension of the same blind spots we documented in our open-source repository extraction guide, our changelog extraction guide, our Kubernetes operator and Helm chart extraction guide, our Terraform module extraction guide, our SBOM extraction guide, our bug bounty extraction guide, and our SOC 2 extraction guide. Open-source repository content covers commit-level contribution mentions. Changelog content covers release-history disclosure mentions. Kubernetes operator content covers cluster-manifest annotation mentions. Terraform content covers infrastructure-as-code module mentions. SBOM content covers regulatory-compliance attested mentions. Bug bounty content covers security-advisory-archive mentions. SOC 2 content covers auditor-attested trust-services mentions. Package-registry content covers release-pressured, content-addressed-immutable, maintainer-attested, downstream-resolution-binding runtime-dependency endorsement mentions made inside the most release-pressured open-source-publication environment any software-producing organization operates — a pillar of the structurally durable public corpus that no other extraction surface can replicate, and the only one where the customer's declaration is consumed by every downstream developer at install time.
This guide describes the extraction workflow for the public package-registry corpus.
Why a package-registry mention beats almost every marketing-elicited testimonial
A dependencies field declaration on the npm registry or a Requires-Dist declaration on PyPI is a category of endorsement that has passed through filters no marketing-elicited testimonial encounters. Six properties stack to make it one of the most adversarially credible runtime-dependency endorsement formats in modern B2B developer marketing.
First, the declaration has been prepared under release-engineering pressure that holds the maintainer accountable. npm packages and PyPI distributions are published by maintainers whose package-ownership and release-signature credentials are visible on the registry and who carry downstream-breakage accountability on every version published. A product mention as a declared runtime dependency, a peer dependency, or a build-time toolchain requirement is being made under the public commitment that the maintainer has accepted release-engineering accountability for the dependency edge. The release-engineering-accountability property is what makes package-registry mentions more credible than mentions in any format that does not carry comparable maintainer-attached accountability.
Second, the declaration has been reviewed through the same release-approval chain that gates every package publish. npm publishes pass through the maintainer's release workflow, which routinely includes a code-review gate on the pull request that bumps the version, a CI gate that runs the test suite, and a publish-token authorization gate that records the publishing identity. PyPI distributions pass through the maintainer's twine upload workflow that requires a registered API token and records the upload event. A product mention in a published package is being ratified by an independent release-approval chain that has CI-exposure on the dependency-resolution accuracy. The release-approval-chain property is what makes package-registry mentions more credible than mentions in any format that does not pass through comparable independent release-engineering review.
Third, the declared dependency edge records a runtime-binding commitment that the package's downstream consumers are bound to. npm dependencies declarations, PyPI Requires-Dist declarations, and Maven <dependency> declarations are resolved into the build of every downstream consumer that installs the package, automatically propagating the dependency edge into the consumer's lockfile and the consumer's runtime environment. A product mention in the dependencies field — as the named upstream package, as the version-range anchor, as the resolution input that drives the lockfile entry — is being made under the runtime-binding dependency that the consumer's build requires that mention to resolve correctly. The runtime-binding property is materially stronger than the equivalent on any format without comparable downstream-resolution attachment.
Fourth, the package is archived in the immutable content-addressed registry record where every version revision is preserved and attributed. npm registry tarballs, PyPI distribution files, Maven Central artifacts, and Cargo crate archives carry SHA-256 integrity attestation that records the exact published content for every version, attestation signatures that record the publishing identity, and metadata audit trails that record which maintainer published which version. A product mention in the published package carries content-addressed attribution that is materially harder to revise after publish than a mention in any format without comparable revision-controlled attribution. The content-addressed-attribution property is what makes package-registry mentions more credible than mentions in any format with editable disclosure.
Fifth, the dependency edge drives the customer's build pipeline and runtime behavior when downstream consumers install the package. npm packages and PyPI distributions are not informational disclosure — they are operational instruments that determine which upstream code is included in every downstream build, which version is resolved into every downstream lockfile, and which dependency edges are included in every downstream SBOM. A product mention as a declared runtime dependency is being trusted by the customer's release-engineering organization to perform reliably enough that the customer's downstream consumers' builds do not break. The operational-trust property is what distinguishes package-registry mentions from informational mentions in formats without comparable operational consequence.
Sixth, the declaration surfaces only in vendor relationships that have crossed the production-runtime-integration threshold. Customers do not declare a vendor as a runtime dependency in a published package unless the vendor's product is actually consumed at install time or at runtime by the customer's downstream consumers. A product mention in a customer's published package indicates that the vendor relationship has crossed the runtime-integration threshold, the release-engineering-approval threshold, and the maintainer-attestation threshold simultaneously. The threshold-crossing property is what makes package-registry mentions a marketing signal of high-value developer-adopting-customer status rather than a generic mention.
The extraction workflow
The workflow runs in four stages: source identification, extraction normalization, dependency mapping, and deployment formatting.
Stage 1 — source identification
Public package registries are scattered across the npm public registry, the Python Package Index (PyPI), Maven Central, crates.io, RubyGems.org, the Go module proxy, NuGet.org, Packagist (PHP), Hex.pm (Elixir/Erlang), and pub.dev (Dart/Flutter). The candidate sources include published package tarballs and wheels, registry metadata pages, maintainer profile pages, package README files extracted from the published artifact, lockfile snapshots from public consumer repositories that resolve the customer package, and reverse-dependency graphs published by the registry.
The source-identification stage screens each candidate registry for three properties: the registry must publish the full package metadata including the dependencies field and the README, the registry must preserve version history with publish-time attribution, and the registry must permit reverse-dependency or dependent-package enumeration to support corpus discovery. Registries that publish only the latest version or that aggregate publishes without per-version attribution are deprioritized.
Stage 2 — extraction normalization
Each candidate package is downloaded as the published artifact (the npm tarball, the PyPI wheel, the Maven jar) and the dependency metadata is extracted from the canonical source (package.json, pyproject.toml or METADATA, pom.xml, Cargo.toml, the .gemspec). The dependency-edge declarations are normalized into a structured record that captures the customer package identity, the customer package version, the declared upstream dependency (the vendor product), the declared version range, the dependency type (runtime, peer, dev, optional), and the publish timestamp. README mentions are extracted separately as platform-of-record mentions and normalized into the same record format with a mention-type marker.
The extraction-normalization stage also captures the maintainer attribution, the publish-signature record where present, and any provenance attestation that the registry exposes (SLSA, Sigstore). This metadata is required for the downstream credibility-scoring stage that distinguishes a one-off solo-maintainer publish from a release-engineering-pressured organizational publish.
Stage 3 — dependency mapping
The dependency-mapping stage joins the extracted records against the customer's commercial relationship database to confirm that the publishing organization is a paying customer, a named customer reference, or a customer in the relationship-management pipeline. The mapping stage also scores the mention strength on three axes: the runtime-binding strength (runtime dependency outranks dev dependency), the package adoption strength (download counts and reverse-dependency counts), and the publish-pressure strength (organizational publish under CI outranks solo-maintainer manual publish). The scored records are sorted by composite credibility and the top decile is promoted to the deployment-formatting stage.
Stage 4 — deployment formatting
Each promoted record is formatted into a deployable testimonial card that displays the customer organization's name, the customer's published package identity, the declared dependency type, the publish date, and an attribution link to the public registry page. The card layout follows the platform-of-origin attribution discipline documented in our testimonial card platform-of-origin attribution guide. The card is deployed alongside the marketing-elicited testimonial inventory but tagged for the package-registry source so that the credibility-attribution surface separates the package-registry mentions from the conventional testimonials.
Why this matters now
Developer-tools and infrastructure vendors compete on credibility signals that the buyer's engineering organization treats as load-bearing during the vendor-evaluation cycle. A dependencies declaration in a public package, a README citation in a widely-installed library, or a peer-dependency requirement in a foundational package is exactly the credibility signal the buyer's engineering organization treats as load-bearing, and it is one of the few credibility signals that the buyer's engineering organization will search for independently during the technical-evaluation stage of the procurement cycle. The vendor that systematically extracts and deploys package-registry mentions captures a credibility surface that the rest of the market has not yet learned to instrument. For the related security-disclosure credibility surface, see our bug bounty extraction guide. For the related infrastructure-as-code credibility surface, see our Terraform module extraction guide.