The sequence the tools impose is the useful part — detect the platform, ask a component for its real token names, then generate — because that is what stops a theme being written against properties that do not exist. It generates only: nothing reads your current theme back, so any drift between the emitted Sass and what is already in the project is yours to reconcile.
The official theming server for Ignite UI, with 13 tools that emit Sass or CSS: platform detection first, then palette, typography, elevation and whole-theme generation, plus per-component token discovery and customisation.
- Platform detection from a project's dependencies and config, which decides the Sass module paths and syntax the generated code uses
- A palette generated from base colours with every shade variation, 50-900 and A100-A700, or a custom palette where you set the 14 shades yourself
- Typography from a font family and a type scale, and elevation shadows across levels 0 to 24
- A complete theme in one call — palette, typography, elevations and the theme application mixin — with spacing and typography included on request
- Size, spacing and roundness set globally or per component through --ig-size, --ig-spacing and --ig-radius-factor, scoped to :root unless you say otherwise
- The exact design-token names a component accepts, returned before you write a component theme against them
- Palette colours as CSS variable references, with contrast and opacity variants
- Reference data read by URI: platform configurations, palette and typography presets, colour guidance and layout documentation
An Ignite UI project the tools can read: detect_platform takes a packageJsonPath, and the platform it reports is what the generated Sass is written against.
One command — npx -y igniteui-theming igniteui-theming-mcp