Trim old versions and download fields from registry listing endpoints - #933
Open
kmturley wants to merge 2 commits into
Open
Trim old versions and download fields from registry listing endpoints#933kmturley wants to merge 2 commits into
kmturley wants to merge 2 commits into
Conversation
The registry root and the four type-list endpoints (GET /, /apps, /plugins, /presets, /projects) previously repeated every published version's full metadata for every package, including each file's url and sha256 - unnecessary until a client actually installs something, and a large share of the payload (~2.45MB raw / ~275KB gzip'd across the current 5 documents). Now those 5 documents keep only each package's latest version, and each file's compatibility fields (architectures, systems, contains, type, size, downloads, attested) so listing-level filtering/sorting stays fully correct, while dropping url/sha256 - the two fields responsible for nearly the entire size win, and the only ones no client needs before an actual install. Org, package, and per-version endpoints are unchanged: full version history, full file data.
CI caught this on a clean checkout: stripSummaryFiles() unconditionally tried to read/write all 5 summary paths, but a registry.export() call that only registers some managers (as the two new tests do, and as any partial build might) never creates the others. My local run had passed by accident on leftover out/ files from an earlier full build.
3 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
GET /,/apps,/plugins,/presets,/projects) previously repeated every published version's full metadata for every package, including each file'surlandsha256- unnecessary until a client actually installs something, and a large share of the payload.architectures,systems,contains,type,size,downloads,attested) so listing-level filtering/sorting (system, architecture, format, etc.) stays fully correct - but dropurl/sha256, the two fields responsible for nearly the entire size win and the only ones no client needs before an actual install.GET /plugins/{org},/plugins/{slug},/plugins/{slug}/{version}) are unchanged: full version history, full file data includingurl/sha256.specification.mdupdated throughout to document the new listing-vs-package-endpoint split.Size impact (current registry data)
(Full
files-array removal was considered and measured at ~69% raw reduction, but was rejected - it brokestudiorack-site's per-plugin detail pages and its system/platform filter, both of which need the compatibility fields at listing time.)Compatibility
open-audio-stack-core'sManager.sync()/install()pipeline andstudiorack-site's listing/detail pages - this shape keeps both working without further changes on their end, sincefiles(and the fields those consumers actually read) is never removed, onlyurl/sha256.versionsto latest-only at the listing tier, which is a schema-shape change for any client that assumed the root/list endpoints carried full version history - flagging for review since it's a spec change, not just an internal optimization.Test plan
npm run format/npm run lint/npx tsc --noEmitnpm test(9/9 passing, including 2 new tests covering the summary-tier trim and confirming org/package/version tiers are untouched)npm run build && npm startagainst real registry data, manually verified shape onlsp-plugins/lsp-plugins(8 versions at org level, 1 version × 4 files withurl/sha256omitted at listing level)🤖 Generated with Claude Code