Uikit3 Laravel Package

Product Decisions This Supports

• Build vs. buy on the boilerplate, not the product. This package adds zero product capability — it collapses roughly one to two days of front-end plumbing (Mix config, asset imports, Blade base layout, login/register/password-reset views) into a single php artisan preset uikit3 command. The PM decision it informs is narrow and real: do we burn sprint capacity wiring Bootstrap-to-UIKit scaffolding, or do we spend that time on the differentiating slice of the MVP?
• UI framework selection, with a cheaper experiment. Because standing up a UIKit 3 prototype stops costing a day, the preset is best framed as an experiment harness — a way to put a UIKit-based clickable slice in front of stakeholders before committing the design system to the roadmap. The cost of being wrong about UIKit drops to hours, which is exactly the condition under which a framework comparison is worth running.
• Time-to-first-demo for internal tools, admin panels, and prototypes. The honest use case is back-office CRUD, internal dashboards, and pre-funding prototypes, where a coherent component library beats brand differentiation and where swapping UI kits later is a contained cost rather than a migration.
• Roadmap risk triage. 46 stars, zero dependents, and a preset system Laravel retired after 5.x–6.x. That combination is a decision input in itself: this is a template to copy, not a dependency to inherit. It should appear in an ADR only as "harvested stubs," never as an approved library.
• Design-system consolidation. If the org has standardized on UIKit 3 (or is evaluating it for its dependency-free JS and small footprint), the preset shortens "can Laravel and our design system coexist?" from an open question to an afternoon spike.
• Deliberate non-decision. The PM's most defensible call here may be no — on Laravel 8+ the correct answer is Breeze/Jetstream plus Vite, and this package should be explicitly scoped out before it lands in a backlog ticket.

When to Consider This Package

Consider it when:

• The app is greenfield on Laravel 5.5–6.x and the team is genuinely choosing a CSS framework now rather than inheriting one.
• The team already has UIKit 3 familiarity and does not want to hand-write the Mix/Babel/Sass wiring for the fourth time.
• The deliverable is a prototype, internal tool, or admin surface where speed beats bespoke design and where replacing the UI layer later is scoped and affordable.
• You want an evaluation artifact: stand up a UIKit slice, compare it head-to-head with Bootstrap or Tailwind equivalents, and decide with something clickable rather than a slide.
• No jQuery, modular CSS/JS footprint is a stated preference — UIKit 3's own JS is dependency-free, which matters for performance-sensitive internal apps and long-lived maintenance.

Look elsewhere when:

• The project is on Laravel 7+. The preset command was removed; the modern equivalents are Breeze, Jetstream, or a starter kit with Vite. Retro-fitting this means fighting the framework, and that cost lands squarely on the roadmap.
• You need an actively maintained dependency with a support path. Zero dependents plus modest stars means any bug is ours to fix, permanently.
• The product has real design requirements — brand system, accessibility conformance, custom components. UIKit 3 gives a coherent baseline, not a differentiator; preset-generated views are scaffolding to be replaced, not shipped.
• You are standardizing on Tailwind or Bootstrap organizationally. There is a maintained Tailwind preset in the same family; picking the orphaned one buys a future migration nobody budgeted for.
• Auth views are meant to ship as-is. Generated Blade auth templates are a starting point; auditing and owning them is non-negotiable.
• You want a repeatable scaffold across many apps. That is a fork-and-own decision requiring an internal owner, not a Composer require.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost accelerator, not a platform bet. It swaps Laravel's default Bootstrap scaffolding for the UIKit 3 framework in one command, removing roughly a day or two of front-end setup from the first milestone of an internal tool or prototype. No licensing cost, no vendor relationship, no production footprint — nothing from this package runs in the request path. The honest caveats: adoption is minimal, the package is effectively unmaintained, and the Laravel feature it plugs into has itself been retired. So we would use it as a starting template we own and fork, never as a live dependency. Framed that way the downside is bounded to a few hours of engineering, and the upside is compressing the "something clickable" milestone.

To engineering: composer require laravel-frontend-presets/uikit3 --dev then php artisan preset uikit3 swaps in UIKit 3 assets, rewrites the Blade layouts and auth views, and rewires the Mix config. Two things to agree before we start: (1) we vendor the generated output into the repo and remove the Composer requirement — it is a 46-star project with zero dependents and we should not be on the hook to it; (2) scope is Laravel 5.5–6.x only — on 7+ there is no preset command, and on 9+ the Mix/Vite split makes the asset scaffolding obsolete, so Breeze/Jetstream plus Vite is the answer there. Run it against a clean tree with a committed baseline, because the preset overwrites files by design and will silently clobber customized auth views or package.json. If the real goal is "pick a UI kit," budget this as a one-week, three-arm spike (UIKit vs. Bootstrap vs. Tailwind) and treat this preset as one arm — plus a cheap way to test whether the team's UIKit ramp-up cost (roughly one to two days, with a materially thinner ecosystem than Bootstrap or Tailwind) is acceptable before we commit the design system to it.