Skeleton Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for developer onboarding. This repository is not a runtime dependency — it is a reference implementation of how to package an opinionated scaffold (preset class + service provider + stub files + Composer wiring). The decision it informs is whether the team invests in a first-class generator or keeps onboarding in a wiki page that decays.

• Standardization vs. team autonomy. If squads pick their own frontend stack (Blade/Tailwind, Inertia+Vue, Livewire), a preset is the lever that makes "the standard" the path of least resistance rather than a policy document nobody reads. The PM decision is whether consistency is enforced by tooling or by convention.

• Roadmap prioritization: is onboarding a differentiator? If time-to-first-PR is a metric the org actually reports on, scaffolding tooling earns roadmap space. If the team ships one or two greenfield Laravel apps a year, it does not — and this evaluation should be closed rather than scheduled.

• Agency/delivery use case. For a shop spinning up many similar client applications, a private preset fork collapses kickoff from days to minutes and enforces the design system, CI config, lint rules, and auth defaults uniformly across engagements.

• Use-case fit is narrow and time-boxed. The tooling targets Laravel's php artisan preset extension point (5.5–5.8 era), which was superseded by laravel/ui, then by Breeze / Jetstream / starter kits. The PM decision is therefore "does the current fleet still use this workflow," not "is this a good pattern" — the pattern is fine, the foundation is deprecated.

• Buy-side signal: a 13-star, zero-dependent artifact. That is expected for a template — nobody composer requires a skeleton — but it means there is no community maintenance to inherit and no downstream consumers to surface regressions. Budget it as source material the org owns outright, not a package it consumes.

When to Consider This Package

Consider it when:

• The team maintains three or more recurring Laravel project shapes and those setup steps are currently copy-pasted by hand.
• The fleet still contains multiple Laravel 5.x applications and php artisan preset is genuinely invoked today, with no near-term framework upgrade.
• You need a starting point for authoring your own generator and want to see the canonical preset structure — provider, command signature, stubs, auto-discovery — before designing your own.
• You are time-boxing a one-to-two day spike and forking is cheaper than authoring from scratch.
• An agency or platform team needs a repeatable kickoff template across many similar client builds.

Look elsewhere when:

• You are on a modern Laravel version — Breeze, Jetstream, and starter kits are the maintained equivalents of what this repo generates, and the preset command it plugs into no longer exists.
• You need a maintained dependency with a release cadence: 13 stars, 0 dependents, and a 0.275 composite score mean no upstream support, no CI evidence, and no issue triage.
• You are scaffolding a package rather than an application — use spatie/package-skeleton-laravel.
• You have exactly one template shape: a documented checklist plus a repo template is cheaper to maintain, does not rot against framework upgrades, and delivers most of the value.
• The Laravel upgrade horizon is under twelve months — an internal composer create-project template or versioned scaffolding repo avoids the deprecated-API coupling entirely.

Non-negotiable precondition for adoption: fork it into the org and own it from day one. Never depend on it directly.

How to Pitch It (Stakeholders)

To executives. This is a free blueprint, not a purchase and not a production dependency. It demonstrates how to package a project template so a new Laravel application — with our auth defaults, design system, CI, and linting already wired — can be generated in one command instead of a half-day of manual setup. Cost is roughly one engineer-week to fork, validate, and document; the return is measured in onboarding hours per project and in consistency across teams. No license fees, no vendor lock-in, and zero production runtime footprint — the only recurring cost is a half-day of re-validation per framework upgrade cycle. Recommend a one-week spike with an explicit go/no-go, benchmarked against simply extending Breeze. Do not adopt if the fleet is about to leave the Laravel versions this targets.

To engineering. Treat the repository as a pattern reference, not a library. It shows the shape of a preset: a preset class, a service provider registered via extra.laravel.providers, stub files, and a command that copies them over a fresh app. Fork it, rename the vendor namespace, vendor the stubs, and either wire it to a modern equivalent of the preset command or — often cheaper — skip the Artisan plumbing and ship a template repo plus a setup script. Three caveats. First, the upstream is unmaintained and effectively single-user: we own all maintenance from day one, with no fixes to pull. Second, preset application is destructive — it overwrites package.json, webpack.mix.js, and resources/assets/* with no dry-run and no rollback, so mandate clean working trees, a framework-version pre-flight check, and a documented recovery step. Third, if Breeze or Jetstream already covers 80% of the target stack, extend those instead; our generator should exist only where we have genuinely opinionated deltas. Validate on a throwaway laravel new app and pilot on one real project before advertising it to teams.