Uikit3 Laravel Package

Technical Evaluation

Architecture fit

• This is a build-time scaffolding generator, not a runtime dependency. It registers a service provider that exposes php artisan preset uikit3; the command copies stub files into the host app — package.json, webpack.mix.js, resources/assets/{js,sass}, the base Blade layout, and the auth views (login, register, password reset). Nothing survives on the request path once the command finishes.
• The architectural consequence is decisive for a TPM: the package's value is fully realized in the first five minutes and decays to zero immediately after. There is no component library, no reusable API surface, and no upgrade channel — just a starting tree of files we own from that moment on.
• Fit is therefore narrow and non-strategic: greenfield Laravel 5.5–6.x apps that have already elected UIKit 3 and want the Mix/Blade/auth plumbing written for them. It should never appear in an architecture decision record as a dependency; at most it appears as a sourcing note on a vendored scaffold.

Integration feasibility

• Install is trivial on the supported band: composer require --dev laravel-frontend-presets/uikit3 followed by php artisan preset uikit3. Auto-discovery registers the provider; no manual wiring.
• The hard ceiling is the preset command itself, removed in Laravel 7 in favor of laravel/ui's ui command. On 7+ the package's primary entry point does not exist, and "integration" degrades to manually instantiating the preset class or, more sensibly, reading the stubs straight out of the repo.
• The stubs assume Laravel Mix (webpack.mix.js, the mix() helper). On Laravel 9+ the default is Vite, so the asset-pipeline half of the deliverable is obsolete for any current LTS target. The Blade layout and auth views remain portable; the build config does not.

Technical risk

• Abandonment risk dominates. 46 stars, 0 dependents, an opportunity score of 0.61 — the upstream is effectively frozen. Every defect, every UIKit bump, every Mix→Vite rewrite is ours.
• Destructive by design. The preset overwrites auth views and asset config in place. On anything other than a pristine tree this can silently clobber customizations. This is the single highest-blast-radius property of the package and drives most of the mitigation below.
• Stale pins in the stubs (UIKit npm version, Mix plugins) will fail npm install/npm run dev against current Node toolchains — a predictable Day-1 friction point on any new machine.
• Small but non-zero supply-chain surface: an unmaintained dev dependency with transitive Composer constraints we did not choose.
• No runtime security exposure (no middleware, no container bindings persist, no request-path code), with one caveat: the generated auth Blade templates are scaffolding to be audited and owned, never shipped as-is.

Key questions

1. What Laravel version and asset pipeline are we targeting? This is the go/no-go gate. If ≥7 or Vite, the package is out and we extract stubs instead — decide this before any estimation.
2. Is UIKit 3 a product requirement or a team preference? Bootstrap and Tailwind have materially deeper ecosystems; if the team is agnostic, the default choice should not be the orphaned one.
3. Clean repo or existing app? Determines whether we run the preset blind (clean tree, committed baseline) or diff-and-merge by hand.
4. Who owns the vendored scaffold — UIKit version bumps, SCSS pruning, layout conventions — and on what cadence?
5. What does composer.json actually constrain? Verify the laravel/framework and illuminate/support ranges before committing a plan to a version band.

Integration Approach

Stack fit

• Fits: Laravel 5.5–6.x + Blade + Laravel Mix + npm/Node.
• Fits with rework: Laravel 7–8 (no preset command; harvest stubs or use laravel/ui + manual npm i uikit).
• Does not fit: Laravel 9+ with Vite; any Inertia/Livewire-first app expecting componentized front-end assets; any org standardized on Tailwind or Bootstrap.

Migration path

• Recommended path: harvest, don't depend. Install on a throwaway branch, run the preset once, git diff the output, lift the artifacts we want (uikit in package.json, the SCSS @import set, the JS bootstrap, the base layout, the auth views) into the app repo, then remove the Composer requirement. The package does its job once and exits the dependency graph.
• If repeatable scaffolding is genuinely needed across multiple apps, fork internally: rewrite the stubs for Vite (vite.config.js, @vite([...])), pin UIKit explicitly, publish under an internal namespace. Only justify this if two or more apps are queued — one app does not amortize a fork.
• The lower-effort alternative for Laravel 7–8 is laravel/ui for auth/asset scaffolding plus npm i uikit and a two-line SCSS/JS import. Functionally equivalent to this preset, backed by a maintained dependency. For most teams this is the better default, and the TPM should ask why it isn't.

Compatibility

• Verify composer.json framework ranges before promising anything; expect a cap at 5.5–6.x.
• UIKit 3 itself is fine — actively maintained, framework-agnostic, dependency-free JS (no jQuery). The constraint is the package's pinned UIKit version, not the library.
• No PHP version conflicts expected (dev-only, no runtime code paths), but confirm auto-discovery registers cleanly on the target Laravel before factoring install time into the plan.

Sequencing

1. Gate: lock the target Laravel version and asset pipeline. Everything downstream depends on this one answer.
2. Spike (half a day): install on a scratch branch, run the preset, git diff, and inventory every file touched. This diff is the deliverable estimate.
3. Decide harvest vs. internal fork vs. reject, based on the diff and on how many apps actually need it.
4. Import through single entry points — one app.scss and one app.js — and confine UIKit markup to one base layout plus a small set of Blade partials, so a future UI-kit swap is a contained cost.
5. Prune the SCSS build to used components only; verify bundle size in CI from the first commit, not after the views accumulate.
6. Validate: npm ci && npm run build, auth flow smoke test, cross-browser check on UIKit JS components (modals, dropdowns, off-canvas).
7. Document provenance — where the scaffold came from, why the Composer dependency was deliberately removed — so a future maintainer doesn't re-add it and re-run the preset over live customizations.

Operational Impact

Maintenance

• Assume zero upstream maintenance; the fork/vendoring owner must be named on day one, not discovered at the first build break. All work — UIKit bumps, Mix→Vite adaptation, security review of auth templates — is internal.
• Track UIKit releases directly from npm/GitHub; this package will never surface them. Add UIKit to the dependency-review routine explicitly.

Support

• No vendor support; community-only through a low-traffic repo. Escalation path is internal by definition — set that expectation before the team files its first issue upstream.
• Ramp-up on the package is minutes. Ramp-up on UIKit 3 is the real cost: the uk- attribute/class API and the UIkit.util.on component model differ enough from Bootstrap that a mid-level developer needs roughly 1–2 days to become productive. Ecosystem coverage (Stack Overflow, tutorials, AI-assisted suggestions) is materially thinner than Bootstrap or Tailwind, which raises per-ticket resolution time for the life of the app — a cost that never appears on the initial estimate.

Scaling

• No runtime scaling concerns whatsoever — nothing on the request path, nothing in the container after install.
• The scaling variable is front-end payload: default UIKit imports are heavy. Enforce the pruned SCSS build and a CI bundle-size check, otherwise page weight grows silently as views are added.
• Team scaling matters more than infrastructure scaling: each new developer pays the UIKit learning tax, and there is no maintained preset to shorten it.

Failure modes

• Preset overwrites customized auth views / package.json — highest probability, highest blast radius. Mitigate by running only on a clean tree with a committed baseline, or by harvesting via git diff rather than running in place.
• Command "preset" is not defined on Laravel 7+ — a silent blocker during onboarding. Document the version ceiling in the repo README, not just in a ticket.
• Stale pinned npm versions breaking installs on current Node — expect this on the first build and budget for it.
• Mix config in a Vite-based environment producing confusing dual-toolchain failures.
• UIKit JS not re-initializing after partial-page navigation (Turbo/Livewire) — requires explicit re-init hooks; without them, components fail intermittently and look like flaky bugs.
• Silent divergence: the team hand-edits generated files, then someone re-runs the preset and loses the work. Removing the dependency after harvesting is the structural fix.

Ramp-up

• Install → first successful build: under an hour, on a matching Laravel version with a working Node toolchain.
• Productive contribution to layouts and components: ~1–2 days, dominated by UIKit fundamentals rather than anything this package provides.
• Full ownership of the vendored scaffold (build config, UIKit upgrades, layout conventions, auth view audit): ~1 sprint for one developer.

TPM recommendation: treat this as a scaffold source, not a dependency. Run it once on a throwaway branch, harvest the stubs into the app, pin UIKit ourselves, target the current asset pipeline, and delete the Composer requirement. The package's only durable value is the Blade layout and auth-view templates — a day or two of engineering — and that value is captured entirely on Day 1. Bounded downside, compressed time-to-demo, no inherited maintenance obligation.