Skip to content

[site feature] Display extension size #367

Closed

Description

@zardoy

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...

Activity

  1. added
    server(Component: server) Backend platform and service-side functionality
    webui(Component: webui) Front-end user interface for open-vsx.org
    on Nov 19, 2021
  2. netomi commented on Dec 12, 2025

    @netomi
    Contributor

    that could be added to the More Info box:

    Image

    Related ticket #1311

  3. netomi commented on Sep 5, 2026

    @netomi
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority:lowNice-to-have or can wait for community contributionsserver(Component: server) Backend platform and service-side functionalitywebui(Component: webui) Front-end user interface for open-vsx.org

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions