Laravel Frontend Preset Laravel Package

Technical Evaluation

What it actually is. calebporzio/laravel-frontend-preset is a build-time scaffolding artifact, not a runtime dependency. It implements the Laravel preset contract (PresetServiceProvider / PresetInterface with install() / uninstall()) and copies opinionated stubs — Tailwind config and CSS entry, app.js, webpack.mix.js, Blade layouts — over a fresh application, then exits. Post-install footprint is near zero, and so is its ongoing leverage. The TPM framing: a template to read and harvest, not a library to adopt.

Architecture fit. Narrow by design. It has no role in API-only services, existing frontends, or apps already on a maintained starter kit. The only defensible fits are (a) a legacy Laravel 5.7–7.x app that already depends on the preset mechanism and needs its mechanics preserved, or (b) a disposable internal prototype that deliberately wants this specific Blade-first, minimal-JS, Tailwind opinion.

Integration feasibility. Direct Composer adoption is technically possible on the versions it targeted but has never been reconciled with the Laravel 8+ removal of php artisan preset, the Vite migration, or subsequent Tailwind and Alpine majors. The honest path is a timeboxed spike: scaffold a throwaway app, inspect the generated file inventory, diff against the target, port only what still applies. Treat any "drop-in" claim as false until src/ and stubs/ are read directly.

Technical risk, split by category.

• Runtime: negligible — at most a require-dev entry; ideally never in composer.json.
• Toolchain: medium-to-high. Stub output is Mix/Webpack-era with 2020-vintage Tailwind and Alpine assumptions.
• Maintenance: high and permanent. Archived, single maintainer, last release 2020-03-03, 31 stars, 0 dependents, no CVE response path.
• Supply chain / compliance: an archived Composer dev dependency is a standing exception with no accountable approver. The audit trail is worse because the package rewrites committed source at install time.
• Bus factor: spike knowledge lands with one or two engineers unless captured in a decision record.

Key questions to resolve before any decision.

1. Which Laravel, laravel/ui, and preset-API versions does it actually target? (v0.1.3 notes only "Laravel 6 and 7.")
2. Exactly which files and dependencies does it write, and what license governs internal forking?
3. Does it deliver anything materially different from php artisan ui tailwind, Breeze, Jetstream, or current laravel new starter kits?
4. If we extract or fork it, who owns it — named engineer, named repo, named update cadence?
5. What is the replication effort to rebuild the useful parts ourselves (thin post-install script plus our own stubs)?

If the answer to (5) is measured in days rather than weeks, ownership beats adoption every time.

Integration Approach

Stack fit. Narrow. The defensible fits are the legacy preset-based app and the disposable prototype described above. It does not fit modern Laravel on Vite, teams on Inertia or Livewire starter kits, or anything with a non-Laravel frontend.

Migration path. Do not commit the package to a long-lived composer.json. The sequence that works:

1. Confirm the business need and that no maintained first-party path covers it.
2. Branch a throwaway repo pinned to a supported Laravel version, composer require --dev, run php artisan preset, commit immediately behind a git checkpoint.
3. Inventory the generated output — package.json, webpack.mix.js, resources/js/app.js, resources/views/layouts/, tailwind.config.js — and diff against the target application.
4. Compare that inventory line-by-line against Breeze / Jetstream / php artisan ui tailwind. Expect substantial overlap; document any genuine differentiator.
5. Port only the still-relevant config and views into the current Vite/Tailwind pipeline, upgrading Tailwind, PostCSS, and Node as you go.
6. Record license provenance, add lockfiles and dependency audit gates, and write an ownership note.
7. Kill the effort if step 4 shows no differentiation — that is a successful spike, not a failed one.

Compatibility. Assume friction with Laravel 8+ (php artisan preset no longer exists), Laravel 9/10+, Vite, current Tailwind, and modern Alpine syntax. Validate the Artisan command against the target version before committing scope; if it errors, extract stubs by hand and move on. Treat every generated dependency version as requiring an upgrade plan.

Sequencing and gating. Run this as a timeboxed DevEx spike of 1–2 days, gated on two checkpoints: (i) the spike yields a documented file inventory plus a clear "differentiated vs. official starter kit" verdict; (ii) a named owner signs up for whatever gets adopted. If either gate fails, close the ticket and standardize on a first-party path. Do not let it expand into a fork project without separate scope and estimate.

Operational Impact

Maintenance. Near-zero if you read it and copy patterns. High — and permanent — if you fork or depend on it: every dependency upgrade, Laravel major bump, and security patch becomes internal work with no upstream to lean on. Budget a fork as a small product with a roadmap, not a one-off install.

Support. No upstream support path exists. No issue triage, no release cadence, no maintainer response, negligible community usage. Teams rely entirely on their own documentation and whoever ran the spike. Assume that person leaves.

Scaling. No production scaling concern — this never runs in a request path. The team-scale risk is different and more insidious: divergent application bootstraps across repos, stale frontend dependencies copied forward indefinitely, and undocumented deviations from Laravel conventions that raise onboarding cost and slow cross-team debugging as headcount grows. Standardization is the scaling lever; an archived preset is the opposite of a standard.

Failure modes to plan against.

• Composer resolution failures or abandoned-package warnings in audits.
• Removal of php artisan preset on Laravel 8+, rendering the tool silently unusable.
• Stale Mix/Tailwind/PostCSS/Node output that fails modern CI.
• Vulnerable transitive dev dependencies with no patch path.
• Destructive, no-merge file overwrites clobbering hand-written views or auth scaffolding.
• Accidental promotion into require and shipping to production.
• Running the preset inside CI or a Dockerfile and rewriting committed source mid-build.
• Configuration drift across apps that each ran the preset at a different time.

Ramp-up. A competent Laravel engineer can evaluate the scaffold and produce a file inventory in roughly half a day to a day. Modernizing the frontend build, or forking for sustained internal use, needs additional frontend toolchain expertise and should be scoped as a small migration project — not a drop-in dependency. Write the spike output into a decision record to collapse the bus factor.

TPM recommendation. Score no adoption as a dependency. Leverage it as cheap prior art: a 1–2 day timeboxed spike to harvest patterns and produce a file inventory, then either standardize on Breeze/Jetstream/php artisan ui tailwind or invest in a thin, named-owner internal starter kit we own outright.