feat: add attested and downloads fields to File/Package types#80
Merged
Conversation
Supports two new registry signals discussed alongside the recent security fixes: - `attested?: boolean` on FileInterface - whether a file has a GitHub Artifact Attestation linking it back to the CI run/commit that built it. Computed once at import time (registry/fetch.ts, in a follow-up PR) since a published file's hash/url/release never change afterwards - unlike `downloads`, this isn't recomputed on every build. - `downloads?: number` at three levels - per-file (FileInterface), per-version rollup (PackageBase, summed via the new packageDownloadsTotal() helper), and per-package rollup across all versions (PackageInterface, via the new Package.getTotalDownloads(), wired into toJSON()). Recomputed at registry build time from the GitHub Releases API (registry/downloads.ts, in a follow-up PR) since download counts change continuously. Both fields are omitted rather than written as `false`/`0` - keeps generated JSON smaller, and neither "not fetched" nor "genuinely zero" is worth distinguishing for either signal. PackageFileValidator extended to type-check them when present. Verified packageDownloadsTotal/getTotalDownloads rollup math directly with dedicated tests (not just zero-value fixtures), and separately end-to-end against live GitHub API data for a real registry package (aaronaanderson/Terrain) during development - see the registry-side follow-up PR for that verification. No behavior change for existing consumers: both fields are optional and additive to the existing schema. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two new optional signals to the shared types, ahead of the registry-side implementation that populates them (opening as a separate PR once this is merged and published):
attested?: booleanonFileInterface— whether a file has a GitHub Artifact Attestation linking it back to the CI run/commit/repo that built it. Computed once at import time (not on every build) since a published file's hash/url/release never change afterwards.downloads?: numberat three levels:FileInterface) — raw download count for that exact file, from the GitHub Releases API.PackageBase) — sum of that version's files, via newpackageDownloadsTotal()helper.PackageInterface) — via newPackage.getTotalDownloads(), wired intotoJSON().Both fields are omitted rather than written as
false/0— keeps generated registry JSON smaller, and neither "not fetched yet" nor "genuinely zero" is worth distinguishing for either signal.PackageFileValidator(Zod) extended so both are type-checked when present, without being required.This PR is types/core-logic only — no network calls, no new dependencies. The registry-side pieces that actually populate these fields (
fetch.tschecking attestations at import time, a newdownloads.tsbatching GitHub GraphQL calls to compute download counts at build time) are ready as a follow-up PR once this publishes.Test plan
npm run build— type-checks cleannpm test— 170/170 passing (5 new tests directly exercising the rollup math with real non-zero numbers, not just zero-value fixtures)npm run lint— clean🤖 Generated with Claude Code