- Does silarhi/tabler-ux-components work with Laravel?
- No. It is a Symfony UX and Twig component library for the Tabler admin template, built on the Symfony UX Toolkit and Twig components, so it will not install or render inside a Laravel/Blade application. Laravel teams would need an equivalent Blade component set or a package that explicitly targets Blade and Livewire. If your stack is Laravel, stop the evaluation here and look for a Blade-native alternative.
- How do I install silarhi/tabler-ux-components?
- Install it with Composer using composer require silarhi/tabler-ux-components, then make sure your application already uses Twig with the Symfony UX Toolkit so the Twig components get registered. You also need the Tabler front-end assets in place, including @tabler/icons-webfont at 3.36.1 or higher for the current release. Always confirm the exact PHP and Symfony version constraints in the package composer.json before adding it to a production project.
- Which Symfony and PHP versions does silarhi/tabler-ux-components support?
- The package targets Symfony applications running Twig with the Symfony UX Toolkit, and the supported PHP and Symfony ranges are declared in its composer.json. Because the project is pre-1.0, that matrix can shift between minor releases, so check the constraint file for the exact version you intend to pin. Verify it against your runtime before planning a rollout.
- How do icons render, prefixed names or the Tabler webfont?
- Unprefixed names such as check keep rendering through the Tabler webfont, so existing templates behave exactly as before. Prefixed names like lucide:circle-check, mdi:account or tabler:check resolve to inline SVG through symfony/ux-icons. The SVG path is opt-in, which means you can adopt it component by component or screen by screen without touching the rest of your UI.
- Do I need symfony/ux-icons to use this package?
- No, symfony/ux-icons is a suggested dependency rather than a hard requirement. Without it, unprefixed icon names still work through the Tabler webfont. If you want inline SVG icons you must add symfony/ux-icons plus the icon-set packages you plan to ship, such as Lucide, MDI or Tabler, and account for their licenses and bundle-size impact.
- How does the filled icon prop work across different icon sets?
- The filled prop resolves to tabler:{name}-filled, so filled variants are only well defined for the Tabler icon set. Lucide, MDI and other sets may not have a matching filled glyph, which can surface as a missing icon or a fallback at render time. Test filled icons per set before standardizing on them in a shared design system.
- Do I need to warm the UX Icons cache in CI and on every deploy?
- Yes. Treat icon import and cache warming as a build and deploy step, the same way you would handle any other compiled asset. A cold cache on a newly provisioned node is a realistic failure point and will show up as missing inline SVG rather than a build error. Add a lint or render test that validates every prefixed icon name used in templates so typos and uninstalled sets fail in CI instead of production.
- Is a pre-1.0 package like this safe to use in production?
- It is usable but comes with the usual 0.x caveats: there is no stated backward-compatibility policy, so minor releases can change rendering behavior. Pin exact versions, subscribe to the changelog and budget a short review per release. The main risk is visual, because supporting both inline SVG and the webfont doubles the regression surface until you standardize on one path.
- What are the alternatives for Laravel or Blade teams?
- There is no drop-in Laravel equivalent because this package is Twig-first and tied to Symfony UX. Laravel teams usually build their own Blade components around the Tabler CSS and JS, or choose a Blade component library aimed at admin dashboards. Inside Symfony, the closest alternative is hand-written Twig includes around Tabler, which this package replaces with consistent, composable components.
- Can I adopt it incrementally and roll back if needed?
- Yes. The 0.8.0 release lists no breaking changes and unprefixed names still go through the webfont, so existing templates keep working untouched. Enable prefixed inline SVG icons per component or screen, and revert those template edits if visual parity problems appear. Only consider removing the webfont once every icon in the application uses a prefixed name.