Closes #367.

Context

The issue asks for the extension size to be displayed, packagephobia-style. Half of what that needs already exists: file_resource.size has been recorded since V1_73__File_Resource_Size.sql (#2089, #2095), set on publish in PublishExtensionVersionService and StorageUtilService, and backfilled for older rows by FileResourceSizeJobRequestHandler. Nothing ever read it back out, though — it reached no API response and no page.

Change

• ExtensionJson.downloadSizes — map of target platform to the size in bytes of the package behind the matching entry of downloads. It is set where downloads is, i.e. on /api/{ns}/{ext} and its versioned variants.
• Web UI — the Target Platforms line on the extension detail page lists each platform in its own row with its size, e.g. Linux x64 12.30 MB, and an info icon beside the heading explains that these are download sizes. Rendered with the existing formatFileSize helper.

Decisions worth calling out:

Per platform, not one number. A version can ship for several target platforms and each package has its own size, so a single size would describe whichever platform the page happened to load. The Download button and its platform menu are unchanged.

It reads the download resource, not a SUM over the version's files. Readme, icon, changelog and license are stored as rows of their own but hold content that is already inside the .vsix, so summing counts it twice.

Unknown is omitted, not zero. A package published before the column existed that the backfill hasn't reached has size = null. That platform is left out of downloadSizes and the UI shows its name alone. A client has no way to tell a zero-byte file from an unknown one, so it gets neither.

Download size, not install size

The issue asks about install size — the reporter's example is a ~110MB .vsix that's over 200MB on disk — and this is the download size. The two differ by the package's compression ratio.

Install size isn't stored and isn't cheaply derivable. Backfilling it means re-reading every existing .vsix out of storage — a much larger job than V1_73's was. That seems worth its own issue and its own decision, rather than holding up the number we already have.

One query, not two

StorageUtilService.getFiles returns the resources and getFileUrls is a shorthand over it, unchanged for its other callers. setDownloads takes the URL and the size from one getFiles call, and the detail builder uses the toFilesJson mapping the other two builders already share, which also removes the duplicated public-key-alongside-signature handling it had grown.

Testing

• RegistryAPITest.testExtensionDownloadSizes / testExtensionDownloadSizesUnknown — the per-platform value reaches the JSON; a null size leaves that platform out.
• extension-detail-overview.spec.tsx (new) — each platform is its own row with its size, a platform without a size is listed by name only, nothing size-like renders when none is known, and the info tooltip appears only when a size is shown.
• FileResourceJooqRepositoryTest (new, Postgres) — findByType and findAll return the stored size, and an unknown size comes back null rather than 0.
• Webui: full suite green, tsc --noEmit and yarn lint clean. Server: full suite green (1823 tests, including the Testcontainers ones).
• Three existing tests stubbed getFileUrls for the detail path and now stub getFiles.

🤖 Generated with Claude Code