How Lumeo stays at 0 KB

The .nupkg bundles everything the package author ships: the compiled DLL, XML documentation, static web assets (CSS + JS files), a Roslyn source generator, MSBuild integration props, and — until rc.40 — a full shadcn-style CLI source registry (~700 KB of JSON). That registry now lives on a CDN as of 3.0.0. Debug symbols ship separately as a .snupkg symbol package, keeping the .nupkg leaner than older builds. None of the above reaches the browser; it only exists so lumeo add and the MCP server can resolve component source offline.

Even the 4.2.0 ~1.18 MB overstates the browser cost because XML docs (96 KB), static web assets (components.js, lumeo-utilities.css, lumeo.css, and smaller JS files totalling ~127 KB), the Roslyn source generator (14 KB), and MSBuild props (~4 KB) never reach the browser — they only matter at development time. And PDB symbols no longer inflate the .nupkg at all: they now ship separately as a .snupkg symbol package. You can verify on nuget.org/packages/Lumeo: the "Download package" badge shows the current .nupkg size.

When you publish a Blazor WebAssembly app with dotnet publish -c Release, the .NET IL linker (trimmer) can remove types, methods, and fields that are unreachable from your entry points — but only for assemblies that opt in with an IsTrimmable marker. As of 4.3.0 (#354), Lumeo.dll sets that flag: a published app that uses one core component now ships a genuinely smaller Lumeo.dll.br than one that uses many. The library's own reflection/dynamic-typing call sites (DataAnnotations validation, the QueryBuilder JSON tree, DynamicComponent-based overlays, JS-interop callback targets) are annotated ([DynamicallyAccessedMembers] / [RequiresUnreferencedCode]) or replaced with source-generated JSON (JsonSerializerContext), so the shrink is real trimming, not a broken build — see "How was this measured?" below.

Trimming also still removes whole satellite assemblies you never reference: skip Lumeo.Charts, Lumeo.DataGrid, or any other satellite package and the linker drops that assembly entirely — it costs you 0 KB. "Install only what you use" is now accurate both at the package level and, for the core, at the per-component level.

Pre-#354 baseline (2026-07-11, 4.2.0): a reference Blazor WASM app referencing every core component, and a second app referencing only <Button />, were each published with dotnet publish -c Release against .NET 10. Both produced a byte-identical (SHA-256-verified) Lumeo.dll.br of 687,723 bytes (671.6 KiB) — the core assembly wasn't trimmable yet, so usage didn't matter.

Post-#354 measurement (2026-07-12, 4.3.0): the same one-component (<Button />-only, samples/CoreTrimDemo in the repo) reference app was rebuilt against the now-IsTrimmable core and republished the same way. Its Lumeo.dll.br measured 116,338 bytes (113.6 KiB) — an 83% reduction from the pre-#354 baseline for this usage shape. A headless-browser load check confirmed the trimmed publish still renders correctly (no console or page errors). An app using most or all 143 core components will still approach the pre-#354 ceiling, since that shape genuinely reaches most of the assembly — trimming reduces cost with usage, it doesn't create free capacity. .NET runtime DLLs (~3–4 MB brotli total) are excluded from every figure above; they're shared across all Blazor apps and cached aggressively by the browser.