Laravel Laravel Package

Technical Evaluation

Critical framing: this is not a library, it is a scaffold — and v2.0.5 finally tells us whose scaffold. The changelog host (github.com/intentui/laravel) resolves the identity question that the previous assessment flagged as unresolved: this is the Intent UI Laravel starter kit, not a generic Laravel skeleton, despite the description reading "The skeleton application for the Laravel framework" verbatim. Intent UI is the Tailwind/React component library formerly published as Justd, which explains the justd/laravel package name and the intentuilabs repo owner — legacy naming from a rebrand, not (necessarily) a re-host. That is a materially better provenance read than "unverified," but it changes the value proposition: you are no longer just adopting a stack, you are adopting a vendor's design system and build toolchain as the foundation of your service. The right question remains "should this be the baseline of our next Laravel service, and can we own it?" — with a new sub-question: "are we prepared to be downstream of Intent UI's release cadence?"

Architecture fit. The backend half is unchanged and still coherent: Laravel 12's slim skeleton (bootstrap/app.php for middleware, exceptions, routing; no Http/Kernel.php or Console/Kernel.php), Inertia v2 + React 19 for a server-routed SPA, Wayfinder for generated TypeScript route helpers, Tailwind v4, Sanctum v4, Pest 3 + PHPUnit 11, Pint, Sail, and Laravel Boost v2 as an MCP server. The frontend half is now more opinionated, not less: Intent UI v4 supplies the component layer, and Vite+ supplies builds, linting, and formatting (Biome is gone). Net effect: the package is an even better fit for greenfield, TypeScript-fluent product teams that want a batteries-included UI kit, and an even worse fit for anyone who intended to swap in their own design system or their own lint/format standard. Teams on Blade/Livewire, Vue, or a separate API + separate SPA are now opting out of three layers (Inertia, Intent UI, Vite+) rather than two.

Integration feasibility. Still low friction at bootstrap, still high irreversibility — and v2.0.5 is the proof case. A 2.0.4 → 2.0.5 patch bump contained an Intent UI major migration (v3 → v4, i.e. component API and styling surface changes) and a full replacement of the build/lint/format toolchain. For a consumer of a published package that would be a semver violation; for a fork-and-own scaffold it is simply "upstream moved, you decide whether to follow." This is the single most useful thing the release tells us: upstream does not version for downstream mergeability. The no-upgrade-channel problem is now empirically demonstrated, which strengthens rather than weakens the fork-and-own recommendation — but it also means the fork diverges faster than the previous estimate assumed. Brownfield adoption remains unsupported; pattern extraction is still the only path there, and the extractable surface is now slightly smaller (the Biome config is gone, replaced by Vite+ config that is harder to lift in isolation).

Technical risk. Revised table:

Key questions for the maintainer/vendor.

1. Confirm license and copyright holder for the scaffold and for Intent UI v4 (component library license may differ from the starter's). Is any part of Intent UI gated behind a paid tier?
2. Is Vite+ a released, versioned, npm-installable dependency, or a preview? What is the exact build/lint/format command surface, and is there a documented fallback to plain Vite + Biome/ESLint?
3. Was the Intent UI v3 → v4 migration documented anywhere (codemod, migration guide, breaking-change list)? Absence of one is a signal about future migrations.
4. What is the maintenance commitment — published support window, security disclosure path, and a policy for tracking Laravel majors?
5. Are Wayfinder and MCP pinned to exact versions or caret ranges? What is the migration plan when they hit 1.0?
6. Is Boost MCP optional or load-bearing? Can the app be built, tested, and deployed with no MCP server in the loop?
7. Which parts are "the product" (config, conventions, AGENTS.md, Intent UI component layer) versus disposable example code?
8. Is the description field going to be corrected? Minor, but it is the reason the previous assessment could not rule out a re-host.

Integration Approach

Stack fit assessment. Adopt wholesale only if all of the following now hold: greenfield service; PHP 8.4 in CI and prod; a team comfortable in React + TypeScript; acceptance of Intent UI as your design system rather than a placeholder; appetite for an early-stage unified build toolchain; a hard Vite/Vite+ build gate in every deploy path; and no requirement to interoperate with existing Blade/Livewire code. The Intent UI and Vite+ conditions are new and are the ones most likely to fail. If any condition fails, fall back to pattern extraction (path B).

Three viable paths, in order of preference.

• A — Fork and own (greenfield services). Vendor the repo into an internal Git host at the v2.0.5 state, tag internal/[email protected], and treat it as your product. Prune: Sail if container-native, Sanctum if no API surface, MCP/Boost if agent tooling isn't approved, Intent UI components you don't use, Vite+ if the toolchain doesn't clear the spike in step 4. Because upstream ships breaking changes in patches, decide explicitly that you will not track upstream and record that in the ADR — cherry-pick security fixes only.
• B — Selective backport (existing apps). Lift the low-risk, high-leverage pieces: bootstrap/app.php configuration, the Wayfinder Vite plugin, pint.json + Pest config, and the AGENTS.md conventions as an internal engineering standard. Drop from the list: the Biome config (now removed upstream) — if you want JS lint/format in an existing app, choose your own tool rather than inheriting Vite+.
• C — Reference only. Read it, cite it in an ADR, don't install it. Correct if the license, Intent UI tier, or Vite+ stability questions go unanswered.

Compatibility envelope. Hard floors: PHP 8.4, Laravel 12, Node with Vite-compatible toolchain, Tailwind v4, React 19. Dependency resolution happens once at scaffold time and is then frozen — good for reproducibility, bad for patching. Plan for quarterly manual merge reviews if you intend to follow upstream at all; realistically most teams should accept permanent divergence and track only Laravel framework security releases. Note that following upstream now also means following Intent UI majors and Vite+ releases, which is a second and third cadence you do not control.

Sequencing (pilot, ~3 weeks — extended by one week versus the prior plan).

1. Day 1–2 — Verify provenance and licenses. License and copyright for the scaffold and Intent UI v4; confirm no paid tier is required for the components you intend to use; confirm tags match Packagist. Answer questions 1–3 before writing code.
2. Day 2–3 — Mirror and pin. Fork to internal Git; pin every dependency to exact versions in composer.lock and the JS lockfile. Tag v1.0.0. No caret ranges in the starter.
3. Day 3–5 — Toolchain spike (new, gating). Stand up the app and exercise build, lint, format, and test under Vite+ on a clean machine and in a clean CI container. Confirm the exact commands and that the production build emits a valid manifest. If this fails or the toolchain is preview-grade with no stable pin, stop and drop to path B or C — do not carry an unstable build chain into a service baseline.
4. Day 5–6 — Scaffold one pilot service. Deliberately a low-stakes internal tool, not a customer-facing launch.
5. Day 6–9 — Prune and re-standardize. Remove unused packages and unused Intent UI components; delete example pages; replace the shipped AGENTS.md with an internal version reflecting your conventions while keeping the test-per-change rule. Document which Intent UI components are approved for use.
6. Day 9–13 — CI parity. composer install --no-dev, JS install + production build (Vite+ or reverted Vite), lint/format check, php artisan test --compact, Pint check. The frontend build step remains non-negotiable — the manifest is a runtime dependency.
7. Week 2–3 — Production deploy + rollback drill. Validate queue workers, scheduler, session/CSRF behavior under Sanctum's SPA configuration, and asset caching. Asset caching deserves extra attention given the build-chain change.
8. Week 3 — Retrofit + ADR. Decide what to backport (path B), record the divergence policy, and name the owners.

Operational Impact

Maintenance. You own this from hour one, and the recurring bill is now larger and less predictable. Baseline: ~0.5–1 dev-day per Laravel minor (quarterly) and 3–5 dev-days per Laravel major (annual). Add: Intent UI majors — v3 → v4 was a real migration, and upstream ships that class of change without a documented migration path; budget 3–5 dev-days each and expect to skip versions rather than track them. Add: Vite+ churn — an early unified toolchain will move faster than Vite did, and a broken build blocks every deploy. Add: the unbounded v0 risk on Wayfinder and MCP (Wayfinder breakage blocks every frontend route call simultaneously). Safest posture: pin Wayfinder hard, wrap its generated helpers in a thin internal module, pin Intent UI components behind an internal re-export layer, and never upgrade more than one of {Laravel, Intent UI, Vite+} in the same sprint. One genuine improvement in this release: removing Biome and unused tooling shrinks the dependency surface and the number of tools a new contributor must learn.

Support. Still no implied support contract — ~163 stars, zero dependents, and a maintainer whose release notes do not include migration guidance. You are the support tier. Mitigations: (a) establish a direct channel with the author and get a response expectation in writing, specifically asking whether Intent UI and the starter are supported products or side projects; or (b) treat upstream as read-only inspiration and make the internal fork the system of record. Do not let the team file upstream issues expecting turnaround. Internally designate one named owner per layer (PHP/backend, Inertia/React, design system, build tooling) — the design-system and build-tooling owners are new and are the ones that will be woken up.

Scaling. Runtime scaling is unconstrained — stock Laravel; PHP-FPM or Octane, Redis, queue workers, Horizon all behave normally. Intent UI and Vite+ are build-time and render-time concerns, not throughput concerns; component-library bloat affects bundle size and Core Web Vitals, not server capacity — worth a bundle-budget check in CI. The real constraint remains team scaling: Inertia + React + Wayfinder + Intent UI demands full-stack TypeScript competency plus familiarity with a niche component library, which narrows the hiring pool further than before. Mitigating factor unchanged and still the most team-scalable asset here: the AGENTS.md conventions (programmatic tests for every change, check sibling files, no unapproved dependency changes, no new base folders) reduce onboarding variance — contingent on enforcing them in CI rather than leaving them as prose. Add one line to those conventions: no Intent UI component outside the approved list, and no toolchain upgrades outside the named owner.

Failure modes to instrument for.

• Frontend build failure or missing manifest in production (Unable to locate file in Vite manifest) — still highest-frequency, lowest-severity; guarantee a build step in every deploy path including previews and container images. Now slightly higher risk because the build chain changed.
• Vite+ regression or abandonment — a preview-grade toolchain can break on a Node upgrade or stall upstream. Detect via a nightly clean-container build on a canary branch; mitigate by pinning exact versions and keeping a documented revert to plain Vite + your chosen linter.
• Intent UI v4 component API drift — props, variants, or Tailwind class contracts shift and screens break at compile or, worse, render wrong. Detect via visual regression or at minimum a storybook/smoke-page set; limit blast radius with an internal re-export layer.
• Loss of lint/format coverage — Biome was removed and replaced by a newer tool whose rule set and editor integration are less mature. Silent coverage gaps let convention drift in. Verify the ruleset explicitly covers what Biome covered; add php artisan test arch tests for PHP-side conventions.
• Wayfinder v0 breaking change — route helper signatures shift, frontend fails to compile. Nightly build on a canary branch; thin wrapper module.
• Upstream disappears or is renamed — mitigated entirely by the internal mirror; still the strongest argument for path A.
• Sanctum SPA auth misconfiguration — cookie domain, SANCTUM_STATEFUL_DOMAINS, CSRF. Test in staging that mirrors production domains, not localhost.
• Inertia deferred props without skeletons — called out in the guidelines; add to the PR checklist or you ship blank flashes.
• Convention drift — AGENTS.md rules decay the moment someone merges a controller with inline validation. Enforce via Pint + Pest arch tests, not documentation.
• MCP/Boost unavailability — search-docs, tinker, browser-logs are the documented debugging path; without the server, developers guess at v12/v2 APIs. Include MCP setup in onboarding or don't mention it.
• Unverified supply chain — identity is now explained, but license/ownership are not confirmed and the release-date anomaly stands. Close before the first composer install; a compromised starter kit is a fleet-wide compromise.

Ramp-up. Backend Laravel developers new to Inertia/React: ~1–2 weeks to productive, ~4 weeks to confident with deferred props, prefetching, and polling — plus 2–3 days for Intent UI v4 (its Tailwind v4 conventions and component composition model are the steepest part of the frontend curve for Laravel-native devs). Frontend React developers new to Laravel: ~1–2 weeks, mostly Eloquent relationships, Form Requests, and the bootstrap/app.php registration model. Wayfinder: a day. Vite+: budget half a day for the named build owner to learn the command surface and CI wiring; everyone else can ignore it if the scripts are wrapped in npm run aliases — do that wrapping deliberately, because it preserves your ability to swap the toolchain without touching CI or docs. Realistic plan: 3 weeks from kickoff to first production deploy for a mid-level pair, with the pilot service doubling as the reference implementation.

Bottom line. v2.0.5 is a net-neutral-to-slightly-negative release for adopters, and a clarifying one. Positive: dependency surface shrank, and the identity question is substantially answered — this is the Intent UI starter kit, and the Justd/intentui naming mismatch is explained rather than suspicious. Negative: upstream shipped a design-system major and a full build-toolchain swap in a patch release, with no migration notes, which is direct evidence that this project will not be merged-with cheaply and that breakage is not confined to majors. Recommendation stands and hardens: adopt as an internal, forked, pinned starter kit for greenfield Laravel 12 services only — not as a tracked dependency, not for brownfield. Add two gates before the fork: confirm Intent UI v4 licensing (and that no paid tier is required), and clear a Vite+ toolchain spike in clean CI — if the build chain is preview-grade with no stable pin, take path B or C instead. The rest remains ordinary engineering discipline.