Laravel Ui Kit Laravel Package

Technical Evaluation

What this actually is. Not a runtime library in the usual sense — it is a scaffolder. ui-kit:install publishes Blade views, Livewire/Volt components, routes, migrations, and config into the host application, patches config/fortify.php, config/admin.php, and routes/admin.php between marker comments, and then gets out of the way. The consequence a TPM must internalize: from the first install onward you own a fork. Upstream fixes only reach you if they land in files the installer re-writes, and re-running the installer over hand-edited published files is a merge problem the package does not solve.

Architecture fit. Strong for one narrow shape: a greenfield Laravel 10–12 app that wants Fortify + Livewire 3 + Volt + Tailwind 3 auth and an admin shell out of the box. Poor for anything else:

• Breeze/Jetstream coexistence is explicitly unsupported and the installer hard-aborts on Jetstream.
• Existing customized Fortify views/actions are silently skipped or overwritten depending on --force.
• The kit assumes a <x-ui-kit::head /> / <x-ui-kit::banners /> master layout and a specific Tailwind preset; retrofit into a design-system-driven app means unwinding its opinions.

Because it is opinionated on four fronts simultaneously (Fortify auth, Volt single-file components, Tailwind preset, Alpine stores), the architectural commitment is larger than "an admin UI" implies. Volt in particular is a paradigm most Laravel teams have not shipped at scale.

Integration feasibility. High, conditionally. The preflight collision check and the explicit publish map are genuinely good TPM-facing artifacts — you can diff the destination list against an existing repo and know your conflicts before running anything. The irreducible manual checklist (User trait, layout tags, Tailwind preset, Vite imports, .env) is small and documented. Realistic effort: ~0.5 dev-day on a fresh laravel new project; 1–2 weeks on a brownfield app where Breeze must be surgically removed first.

Technical risk. This is the dominant factor and it is severe.

• Zero stars, zero dependents, zero score. No production signal whatsoever. Treat as unproven.
• Bus factor of one. No governance, no security policy, no contributor base evident.
• Release posture unclear. The README ships a whole appendix on installing via VCS/path repository "until a version is tagged and submitted to Packagist" — meaning there may be no semver release to pin. Pinning dev-main in a production app is a supply-chain practice most orgs forbid.
• Version claims outrun CI. README advertises Laravel 13; CI covers PHP 8.1–8.4 × Laravel 10/11/12. That gap is exactly where breakage hides.
• Documentation defect. The excerpt truncates mid-@include in the GA4 section — a signal that the README is not linted and may not be trustworthy on detail.
• Silent-failure surface. The README itself warns that without Breeze's --force handling "Laravel silently skips them, leaving you with Breeze's code running under this kit's layouts — usually broken." Silent partial installs are the worst class of scaffolding failure.
• Blast radius. Installer runs migrate, storage:link, npm install, and vendor:publish for every transitive dependency. That is a lot of side effects from one artisan command.

Key questions to resolve before any commitment

Integration Approach

Stack fit. Adopt only where the target app is already converging on the Laravel 10–12 + Livewire 3 + Tailwind 3 baseline. Reject if any of the following are true: Jetstream present, Sanctum-token-centric API auth in play, a bespoke design system with its own Tailwind config, or Fortify actions already customized.

Recommended consumption model: fork-and-vendor, not composer require. Given zero dependents and no clear release channel, treat the repository as an internal template. Clone it into an internal platform/ui-kit fork, tag our own 1.0.0, and require that via VCS. This:

• decouples us from upstream disappearing,
• lets us own the Laravel 13 verification,
• gives us a place to patch the installer.

Cost: we absorb upstream maintenance. Benefit: we can actually ship.

Migration path.

Compatibility gates. Lock PHP and Laravel to a matrix row the CI actually proves (PHP 8.2/8.3 × Laravel 11/12). Do not accept the Laravel 13 claim without running the full install + smoke test yourself. Node 18+ and a working Vite/Tailwind build are hard prerequisites — confirm before scheduling.

Sequencing.

1. Spike (2–3 days, throwaway repo). Install core + two or three modules (admin-middleware, profile, impersonation). Exercise login, password reset, admin CRUD, impersonation ribbon. Time-box; deliver a go/no-go memo.
2. Fork and pin. Internal fork, own tag, composer.json points at our VCS. Record the upstream commit SHA.
3. Decide the module set once. Modules are additive but each adds composer deps, migrations, config publishes, and a manual "Next steps" checklist. Enumerate up front; retrofitting activity-log or support-tickets later means another installer run against a live codebase.
4. Greenfield scaffold or brownfield de-Breeze. Brownfield: remove Breeze in an isolated branch, install, diff, review every published file before merging.
5. Complete the manual checklist in one PR (User trait, layout tags, Tailwind preset, Vite imports, .env, npm run build, admin role assignment). Do not leave these scattered.
6. Harden before first deploy (see Operational Impact).
7. Freeze and document. Publish an internal ADR stating: published files are ours, upstream re-sync is manual, upgrades are re-evaluated per Laravel minor.

Lock-in note. Lock-in here is not to the vendor — it's to the generated code. Because it's Blade + Livewire + Fortify, the exit cost is rewriting screens, not escaping an SDK. That is a favourable property and should be stated explicitly in the ADR; it's the strongest argument for proceeding.

Operational Impact

Maintenance. The recurring cost is not dependency bumps — it's drift management for ~20+ published files. Every Laravel or Livewire minor version forces a decision: re-run the installer (safe for marked config/nav/route blocks, risky for published views) or hand-patch. Budget 1–2 engineer-days per Laravel minor release for verification and patching, plus ad-hoc time for Tailwind 3 → 4 whenever the host app upgrades. Because published files are hand-customized, there is no clean three-way merge — assume manual review.

Support. No vendor, no community, no SLA, no security disclosure channel. Operationally this means:

• Designate an internal owner for the fork on day one.
• Subscribe to the upstream repo and CHANGELOG; a single-maintainer project can go dormant without notice.
• Maintain a written patch log of every local divergence so a future re-sync is tractable.
• Do not place this on a path where a stalled upstream blocks a release.

Scaling. Mostly a UI concern, so application scaling impact is low — but several modules are not purely cosmetic:

• analytics pushes UTM-capture middleware into the global web group. Every authenticated request gets extra work and writes; verify it doesn't become a hot path or a PII sink.
• activity-log and support-tickets add tables that grow unbounded — plan retention/pruning before launch, not after.
• impersonation (lab404) is a privileged capability; it needs an audit trail and role gating, not just the exit ribbon.
• admin-middleware introduces Spatie permissions; cache invalidation on role assignment is the classic production gotcha.
• Sidebar badge resolvers run on admin page render — bind them to cached/aggregate queries, not per-request counts.

Failure modes to instrument or test explicitly.

Ramp-up. Non-trivial despite the "2 minutes to working UI" pitch. The team needs Livewire 3 and Volt and Alpine fluency to customize rather than just accept the defaults. Volt's single-file component model is unfamiliar to most Laravel developers; expect 2–4 days of genuine productivity loss on first customization, more if the team is Breeze-trained (muscle memory actively misleads here).

Exit plan (state it in the ADR). The kit is a Blade/Livewire/Fortify implementation. If upstream dies or diverges, the escape route is to freeze the fork permanently and maintain it as first-party code. Because there is no proprietary runtime, that route is viable — which is precisely why a fork-and-own posture is the right call and a direct composer require on an untagged, zero-adoption package is not.

Recommendation. Approve as an internal greenfield accelerant under a fork, with a 3-day spike gate and a named owner — do not approve as a production dependency on dev-main, and do not attempt on Breeze/Jetstream bases. Re-evaluate only after the project demonstrates a tagged release, a second maintainer, and CI coverage matching its advertised Laravel support.