# Go fully standalone (eject)

Source: https://lumeo.nativ.sh/docs/guides/go-standalone

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

## See also

-   [Vendor a component](docs/guides/vendor-a-component) — the single-component starting point.
-   [Customize a vendored component](docs/guides/customize-a-component) — edit source and manage drift.
-   [CLI reference](docs/cli) — `init`, `eject`, and every flag.
