You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I think it would be useful to display install size in WebUI. I always wanted to have something similar to https://packagephobia.com/. I saw thousand of times developers bundling huge .map files or even whole node_modules.
I hope authors in this case will pay more attention to the bundling process. I even saw an extension that had ~110MB .vsix size and more than 200MB on disk. This extension was like installing forever...
Picking this up — with a correction to the state of play first: file sizes are already stored.file_resource.size arrived with V1_73__File_Resource_Size.sql (#2089, then #2095), is set on publish, and is backfilled for older rows by FileResourceSizeJobRequestHandler. What was missing is that nothing ever read it back out: it reached no API response and no page.
#2168 closes that gap — ExtensionJson.downloadSize plus a Size entry in the More Info box, next to the unique identifier, as suggested above.
One thing this does not answer
The request here is for install size — the ~110MB .vsix that turns into 200MB on disk. What ships in #2168 is the download size. The two differ by the package's compression ratio, which is precisely the point being made about bundled .map files and stray node_modules, so this is a partial answer rather than a complete one.
Install size isn't stored today. It is computable at publish — the code already walks zip entries in ArchiveUtil and SecretDetector, and ExtensionVersionIntegrityService sums entry.getSize() into the signature manifest — but backfilling it means re-reading every existing .vsix out of storage, a substantially bigger job than V1_73's was. That deserves its own issue and its own decision rather than blocking the number already sitting in the table.
Happy to open a follow-up for the unpacked size if there's appetite for the backfill.
Activity
netomi commentedon Dec 12, 2025
that could be added to the More Info box:
Related ticket #1311
netomi commentedon Sep 5, 2026
Picking this up — with a correction to the state of play first: file sizes are already stored.
file_resource.sizearrived withV1_73__File_Resource_Size.sql(#2089, then #2095), is set on publish, and is backfilled for older rows byFileResourceSizeJobRequestHandler. What was missing is that nothing ever read it back out: it reached no API response and no page.#2168 closes that gap —
ExtensionJson.downloadSizeplus a Size entry in the More Info box, next to the unique identifier, as suggested above.One thing this does not answer
The request here is for install size — the ~110MB
.vsixthat turns into 200MB on disk. What ships in #2168 is the download size. The two differ by the package's compression ratio, which is precisely the point being made about bundled.mapfiles and straynode_modules, so this is a partial answer rather than a complete one.Install size isn't stored today. It is computable at publish — the code already walks zip entries in
ArchiveUtilandSecretDetector, andExtensionVersionIntegrityServicesumsentry.getSize()into the signature manifest — but backfilling it means re-reading every existing.vsixout of storage, a substantially bigger job than V1_73's was. That deserves its own issue and its own decision rather than blocking the number already sitting in the table.Happy to open a follow-up for the unpacked size if there's appetite for the backfill.
feat: expose the extension package size in the API and web UI
feat: expose the extension package size in the API and web UI
feat: expose the extension package size in the API and web UI
feat: expose the extension package size per target platform
feat: expose the extension package size per target platform (#2168)