- How do I install LaraLiveUI in a Laravel Livewire application?
- Run composer require elnasnato/laraliveui, then add @laraliveuiAppearance inside your layout's head and @laraliveuiScripts after @livewireScripts at the end of the body. Import the package stylesheet in resources/css/app.css with @import '../../vendor/elnasnato/laraliveui/dist/laraliveui.css' below @import 'tailwindcss', and add the dark custom variant. No package-specific npm or Vite build step is needed beyond compiling Tailwind.
- What Laravel, Livewire, and Tailwind CSS versions does LaraLiveUI require?
- The package requires Laravel 10.0 or newer, Livewire 3.5.19 or newer, and Tailwind CSS v4.0 or newer. The Livewire requirement is a patch-level pin rather than a major version, so older Livewire 3 releases will not work. Tailwind v4 is the hard constraint for most teams and usually the deciding factor in adoption.
- Does LaraLiveUI work with Tailwind CSS v3?
- No. LaraLiveUI is built for Tailwind CSS v4 and its components rely on v4 features, so projects still on v3 or v3 compatibility shims cannot adopt it without upgrading Tailwind first. That upgrade is a framework-level change to your CSS pipeline, so budget for it separately from the component work itself.
- How do I use LaraLiveUI components in a Blade template?
- Components use a namespaced tag syntax with the laraliveui: prefix, for example <laraliveui:button variant="primary">Click me</laraliveui:button> or <laraliveui:input name="email" />. Compound components such as modals, dropdowns, and tables use dot notation for their parts, like laraliveui:modal.trigger and laraliveui:table.column. A custom LaravelLiveUI tag compiler handles the colon syntax, so no manual Blade component registration is required.
- Can I override or customize individual LaraLiveUI components?
- Yes. Running php artisan laraliveui:publish copies component views into your own application so you can edit them directly, and it is the main way to de-risk the package. Because overrides live in your repository, you are not fully dependent on upstream for any component you have published. Theming also uses CSS custom properties with a --laraliveui- prefix and data-laraliveui-* attributes you can target without forking.
- Can LaraLiveUI be used alongside FluxUI or another component library?
- Yes. The namespacing is deliberately defensive: the laraliveui: tag prefix, a window.LaraLiveUI global, a $laraliveui Alpine store, and prefixed CSS tokens and data attributes mean it can coexist with FluxUI, Sheaf UI, or a bespoke component layer. That makes incremental adoption realistic, letting you migrate page by page rather than rewriting everything at once.
- Is LaraLiveUI free, and what is the licensing status of its ported pro components?
- LaraLiveUI is described as a free, community-driven open-source component library, but its own AGENTS.md describes it as a UI clone of FluxUI v2, including the 18 components that are commercially licensed in the original. Treat that as a legal gate rather than an engineering preference, because if the ported pro components are derivative, a license claim or takedown could force a rework of any UI built on them. Get written legal sign-off before production and consider isolating the pro set from the free set in your codebase.
- Why are Tailwind classes missing from LaraLiveUI components after install?
- Importing a prebuilt CSS file from vendor/ bypasses Tailwind v4 source detection, so utility classes used only inside the package's Blade views can be dropped from your build. Add @source directives pointing at the vendor Blade paths, or publish the components into your own resources so Tailwind scans them normally. Missing styles in dynamically generated markup are usually this same issue.
- Where should @laraliveuiScripts go, and does LaraLiveUI work with route:cache?
- Place @laraliveuiScripts after @livewireScripts, since directive ordering matters and the package's JavaScript depends on Livewire and Alpine being loaded first. The JavaScript is served through AssetManager routes, which can break under route:cache or aggressive CDN caching; publishing the assets to public/ for a CDN origin avoids that failure mode. Test with route:cache enabled in staging before deploying to production.
- Is LaraLiveUI actively maintained, and does it have a changelog or CI?
- It is a single-maintainer project with no organization backing, which is a real bus-factor risk for a core UI dependency. The release notes for v1.0.0, v1.0.4, and v2.0.0 have empty changelogs and there is unresolved version drift between the documented latest tag and the published releases, so upgrade risk cannot be assessed from the repo alone. There is also no visible CI, test suite, supported-version matrix, or accessibility audit, so verify tags on Packagist and pin a version you have tested.