Go fully standalone (eject)

Vendoring a component still leaves one thread to the package: the shared runtime — the services, the Cx class-merge helper, the theming types, and the icon system your components inject and reference. Going standalone cuts that thread too: the CLI vendors the runtime as source into _LumeoRuntime/ and strips the Lumeo package reference. End state: zero Lumeo NuGet, a project that builds entirely from source you own.

Two ways in: start standalone with lumeo init --standalone, or convert an existing package-based project with lumeo eject.

Path A — Start standalone

In a fresh Blazor project with no Lumeo package, run lumeo init --standalone. Since there is no package to supply CSS/JS, init also sets up assets (option 1 copies Lumeo's pre-built CSS/JS into wwwroot/). The config records "standalone": true.

$ lumeo init --standalone
Lumeo NuGet was not detected in any nearby .csproj.
...
 Option 1: Copy pre-built CSS/JS into wwwroot/
  +   wwwroot/css/lumeo.css
  +   wwwroot/css/lumeo-utilities.css
  +   wwwroot/js/theme.js
  +   wwwroot/js/components.js

OK Wrote lumeo.json
  namespace       StandaloneDemo.Components
  componentsPath  Components/Ui
  registry        https://lumeo.nativ.sh/registry.json
  assets.mode     prebuilt

Next: lumeo add button

The first lumeo add now does more than copy one component. It vendors the entire runtime closure into _LumeoRuntime/ (kept in the Lumeo namespace, verbatim), mirrors the core JS/CSS under wwwroot/_content/Lumeo/, then writes the component itself:

$ lumeo add button
  +   _LumeoRuntime/ (75 Lumeo runtime files)
  +   wwwroot/_content/Lumeo/js/components.js
  +   wwwroot/_content/Lumeo/js/theme.js
  +   wwwroot/_content/Lumeo/js/signature-pad.js
  +   wwwroot/_content/Lumeo/js/toolbar.js
  +   wwwroot/_content/Lumeo/css/lumeo.css
  +   wwwroot/_content/Lumeo/css/lumeo-utilities.css
  +   Components\Ui\Button\Button.razor
  +   Components\Ui\Spinner\Spinner.razor

OK Added Button (+1 dep) - 2 files written to Components/Ui/

What the runtime contains

_LumeoRuntime/ is the shared closure every component leans on — services, extensions, theming, and the primitive enums (Size, Side, Density, …). Critically, the icon system ejects too: Icons/LumeoIcons.g.cs and UI/Icon/SvgGlyph.razor are first-party, so a standalone project needs no external icon NuGet at all.

Components/Ui/_LumeoRuntime/
├─ Icons/
│  └─ LumeoIcons.g.cs      # the icon set ejects too — no icon NuGet
├─ UI/
│  └─ Icon/SvgGlyph.razor  # the SVG glyph renderer
├─ Services/               # ComponentInterop, Theme, Toast, …
├─ Theming/
├─ Internal/               # Cx class-merge helper, etc.
├─ Extensions/
├─ Attributes/
├─ Size.cs  Side.cs  Density.cs  Orientation.cs  …
├─ IconSource.cs
└─ _Imports.razor

The vendored runtime keeps the Lumeo namespace on purpose — inter-component references all bind under it — so init --standalone / eject append the bridging @using Lumeo, @using Lumeo.Services, … to your root _Imports.razor so <Button> and friends keep resolving.

Path B — Eject an existing project

Already using the Lumeo package with a few components vendored? Run lumeo eject. In one shot it vendors the runtime, re-vendors every already-installed component as source (keeping the Lumeo namespace this time), then removes the <PackageReference Include="Lumeo" /> from your .csproj:

$ lumeo eject
  +   _LumeoRuntime/ (75 Lumeo runtime files)
  +   wwwroot/_content/Lumeo/css/lumeo.css
  ...
  +   Components\Ui\Button\Button.razor
  +   Components\Ui\Spinner\Spinner.razor

OK Ejected - vendored components now build with no Lumeo NuGet reference.
  Removed PackageReference: Lumeo
  Runtime vendored to Components/Ui/_LumeoRuntime/

Eject is careful: it vendors the runtime first and only strips the package once that succeeds — so a failure never leaves you half-ejected. If you used a satellite package (Charts, DataGrid, …) via the default NuGet flow, eject keeps that reference and tells you to run lumeo add <component> --vendor then lumeo eject again to finish.

Verify: zero Lumeo, clean build

The proof is a build with no Lumeo package on the graph. Confirm the reference is gone, then compile:

$ grep -c 'Include=\"Lumeo\"' StandaloneDemo.csproj
0

$ dotnet build -c Release
  StandaloneDemo -> bin/Release/net10.0/StandaloneDemo.dll
  StandaloneDemo (Blazor output) -> bin/Release/net10.0/wwwroot

Build succeeded.
    0 Warning(s)
    0 Error(s)

The .csproj now references only the framework Blazor packages — every Lumeo type resolves from _LumeoRuntime/. You own the whole stack.

Trade-offs

Concern	Package mode	Standalone
Updates	Bump the version, get everything.	Per component via `lumeo update`; runtime refreshes on registry bumps.
Ownership	Components vendored; runtime in the package.	Everything is source in your repo.
Dependencies	`Lumeo` (+ any satellites).	Framework Blazor packages only.
Repo size	Small — a package reference.	Larger — the runtime lives in your tree.

Standalone is the maximum-ownership, air-gap-friendly end of the spectrum. Most projects never need it — but when you must vendor everything (strict supply-chain review, a long-lived fork), one command gets you there and the build proves it.