Laravel Frontend Preset Laravel Package

Product Decisions This Supports

• Build vs. standardize on developer scaffolding. This package is a concrete artifact of the "personal preset" pattern — one maintainer's opinionated frontend scaffold for new Laravel apps. It is most useful as evidence in the decision of whether to maintain a house starter kit or standardize on a maintained first-party path (Laravel Breeze, Jetstream, laravel/ui, php artisan ui tailwind, or the current laravel new installer). Its own lifecycle — archived, last release 2020-03-03, 31 stars, zero dependents — is the strongest argument against bespoke presets with no named owner.
• Frontend stack standardization. The preset swaps Laravel's default Bootstrap/Vue scaffolding for a lightweight Tailwind CSS + Alpine.js, Blade-first setup, wired through a single Artisan preset command. That makes it a useful input to a frontend standards RFC: "here is one credible practitioner's default," not a mandate. Confirm exact contents (base Blade layout, auth views, webpack.mix.js) by reading stubs/ before citing specifics.
• Migration and upgrade scoping. For teams still running Laravel 5.5–7.x apps that used the old php artisan preset mechanism, this is a working reference for what that mechanism actually did and how the shift to laravel/ui changed scaffolds. Directly informs effort estimates on legacy upgrades and on decommissioning preset-based bootstraps.
• Roadmap signal on DevEx investment. Preset-style scaffolding has a short half-life: php artisan preset was removed in Laravel 8, and the Mix/Webpack assumptions here are stale against Vite. That supports a roadmap decision to fund a maintained first-party path plus a thin, owned post-install script, rather than a forked or vendored package.
• Onboarding metric design. Useful as a prototype input for measuring time-to-first-commit and time-to-first-deploy against a customized scaffold — a DevEx KPI on the engineering scorecard, not a customer-facing feature.
• Explicitly out of scope: no customer-facing feature, pricing, packaging, or go-to-market decision is informed by this package. It has no product surface area and no runtime role in production.

When to Consider This Package

Consider it only when:

• You maintain a legacy Laravel 5.x/6.x/7.x application that already relies on the old preset mechanism, and you need the shim or its mechanics as a reference to keep or unwind it.
• You want prior art to fork into an internal starter kit your team will own, version, test, and patch — treat the fork, not the package, as the product.
• You are running a timeboxed DevEx spike or competitive scan and need a concrete example of opinionated scaffolding, plus a reference implementation for writing your own PresetServiceProvider and stubs.
• You have Laravel/PHP engineers who can read the source, run a throwaway scaffold, diff the output, and re-implement patterns rather than depend on it.

Look elsewhere when:

• Starting a new project. Use Laravel Breeze, Jetstream, laravel/ui, php artisan ui tailwind, or the built-in laravel new starter kits — all maintained and versioned against current Laravel.
• You need support, SLAs, or security patching. Archived since 2020, single maintainer, zero dependents, no release cadence, no CVE response path. An archived, unmaintained Composer dev dependency is a standing exception request with no accountable owner.
• Supply-chain or compliance review applies. Same conclusion, and the audit trail is worse because the package rewrites committed source files at install time.
• Your team lacks capacity to own a fork. Adopting without ownership converts a one-day scaffolding task into an ongoing maintenance liability — Tailwind, PostCSS, Node, and Laravel compatibility all move under you.
• Your target is Laravel 8+. The php artisan preset command no longer exists; the stub output is Mix-era and pre-current-Tailwind. Extraction is manual, not a drop-in install.

How to Pitch It (Stakeholders)

To executives: We evaluated calebporzio/laravel-frontend-preset and recommend no adoption as a dependency. It is a personal, archived frontend preset (31 stars, 0 dependents, last release March 2020) with no maintenance, no support path, and no security response. There is no license cost, but adopting it creates an unowned dependency and a guaranteed future migration. Its real value is cheap prior art: it validates a minimal-JS, Blade-first, Tailwind-based scaffold and gives us a reference to copy from rather than design blind. Recommended action: a 1–2 day timeboxed spike to harvest patterns, then either adopt the maintained first-party scaffolding or build a thin internal wrapper we own outright.

To engineering: Don't add this to composer.json. Read it, fork the ideas, and if we want a house preset, we own it — versioned, tested, and tracked against the Laravel major we're on. The interesting parts are the preset mechanics (PresetServiceProvider / PresetInterface, install()/uninstall()) and the opinionated Tailwind-plus-Alpine defaults in stubs/, not the package itself. Practical notes: the preset copies files wholesale with no merge semantics, so run it only on a fresh app or behind a git checkpoint; never run it in CI or a Dockerfile, because it rewrites committed source; and don't edit vendor/ in place. Estimate replication effort first — if owning the scaffold costs a few days, that beats depending on an abandoned repo.

One-line framing: a useful artifact, not a dependency — evaluate it as a template, budget zero for support, and spend the saved effort on scaffolding we control.