Skeleton Laravel Package

Technical Evaluation

Architecture fit. The first TPM instinct on this repo is to reclassify it: it is not a dependency to be vetted, it is source material for a capability we would build. Nothing here runs in a request cycle, ships to production, or introduces a transitive dependency surface. The package's entire technical contribution is a PresetServiceProvider plus a preset command that copies stubs onto a fresh Laravel application — a developer-workstation tool, invoked once per project. Fit is therefore binary and gated by framework generation: it targets Laravel's php artisan preset extension point (5.5–5.8), which was removed in Laravel 6 and functionally replaced by laravel/ui, then Breeze/Jetstream, and now the official starter kits. On any modern Laravel line there is no slot to plug this into. The TPM-level question is not "does the architecture fit?" but "do we still have a fleet segment operating on the extension point this serves?" — and if not, this artifact's architectural value is zero regardless of code quality.

Integration feasibility. Mechanically low-risk and clearly bounded: fork, rename the vendor namespace, strip the demo preset, substitute our stubs, register the provider, publish internally. A competent Laravel engineer reaches a first working internal preset in two to five days. The genuine feasibility constraint is leverage — a preset is a multiplier on repetition, so it only pays back where greenfield creation is recurring. Two or three projects a year does not clear the bar against composer create-project templates or documented checklists; a steady stream of similar apps (agency delivery, multi-tenant product line, platform with many services) does. This is the central ROI judgment a TPM should own and defend, because engineering effort estimates alone will look deceptively small.

Technical risk. High relative to the value delivered, and the risks are management-shaped as much as code-shaped:

• Lifecycle risk (critical). Built against a superseded framework extension point. Adoption anchors onboarding tooling to a Laravel generation the org presumably intends to leave. Any forked preset has a defined obsolescence date tied to the Laravel upgrade roadmap — put it on the roadmap explicitly rather than discovering it during an upgrade.
• Destructive operations (high). Preset application overwrites webpack.mix.js, package.json, assets, and auth views with no dry-run and no rollback. This is a workflow hazard for developers and a support burden for the platform team.
• Maturity signal (high). 13 stars, 0 dependents, composite 0.275. That is normal and even expected for a template — nobody composer requires a skeleton — but it means zero community validation, no evidence of CI, and no downstream consumers to surface regressions. Every file is unreviewed code owned by whoever forks it.
• Ownership transfer (structural). "Adopting" this means becoming the maintainer of a fork from day one. There is no upstream to pull fixes from, which is a permanent, unbudgeted line item unless made explicit.

Key questions.

1. What Laravel versions are actually in the fleet, and is php artisan preset invoked anywhere today? (This single answer decides whether the artifact is live or archival.)
2. Is the desired business outcome "author a reusable preset" or "make new-project setup fast and consistent"? The second has cheaper, longer-lived solutions.
3. Who owns the fork as a named individual and as a team, and what is its deprecation date against the Laravel upgrade plan?
4. Does the skeleton include a working example preset or tests we can validate against, or is it scaffolding plus prose?
5. Is PHP 8 / Composer 2 compatibility verified, or is this PHP 7-era code requiring modernization before first use?

Integration Approach

Stack fit. Requires Composer, Laravel 5.5–5.8, PHP 7.x (PHP 8 unverified), and npm with Laravel Mix. Registration follows Laravel package auto-discovery via extra.laravel.providers, with commands registered through the provider. A fork inherits those conventions unchanged; the only work is namespace and stub replacement. Nothing here integrates with CI, observability, or deployment — it lives entirely in the local bootstrap path.

Migration path. Sequence for a fork-based adoption:

1. Fork to internal VCS, rename to acme/laravel-preset, strip the demo preset.
2. Replace stubs with our canonical package.json, webpack.mix.js, Tailwind/Sass config, ESLint/Prettier, and base Blade layouts.
3. Publish to an internal Composer registry, tag 0.1.0 as explicitly internal-only.
4. Validate against a throwaway laravel new application — never a real project.
5. Pilot on one genuinely greenfield app, document the rollback procedure, then advertise.

Decision gate (do this before forking). Compare against a versioned composer create-project template or scaffolding repo. That alternative delivers most of the value with no coupling to a deprecated Artisan extension point and no PHP 7-era code to modernize. This is the highest-leverage call in the assessment and should be made and recorded before any engineering time is spent.

Compatibility. Watch for Artisan signature collisions if laravel/ui is co-installed, hard-coded stub paths that break on directory-layout shifts, and Composer 2 plugin/script behavior. Treat PHP 8 support as unproven until tested.

Sequencing. Fleet inventory → one-day spike on a throwaway app → go/no-go on preset vs. create-project template → pilot with documented rollback → support handoff. The inventory step gates everything; skipping it risks building a tool for a framework generation the org is exiting.

Operational Impact

Maintenance. Total and permanent. There is no upstream cadence to inherit and no issue triage to rely on. Every Laravel minor upgrade forces re-validation of stubs, path assumptions, and Mix config. Budget roughly half an engineer-day per framework upgrade cycle, plus ad-hoc fixes when a consuming team hits a broken scaffold. Track this as a recurring cost in the platform team's capacity plan, not a one-time build.

Support. Internal-only, first-line support sits with the platform team. No vendor, no community of scale, no dependents to consult — support quality equals the quality of the documentation written during the pilot. That documentation should be a named deliverable with an owner, not an afterthought.

Scaling. Effectively no infrastructure concern: no runtime footprint, no request-path latency, no data plane. "Scale" here is the count of new projects bootstrapped per quarter. Value scales linearly with that count while maintenance stays roughly flat — the one genuinely favorable characteristic in this evaluation, and the reason a preset is worth considering at all where greenfield volume is high.

Failure modes. Ranked by likelihood and blast radius:

• Partial application — files copied but composer install/npm install not run, or vice versa; half-scaffolded repo.
• Silent overwrite of app-specific webpack.mix.js or package.json when applied to a non-pristine project.
• Stub drift after a framework layout change → builds locally, fails in CI.
• Provider not discovered in non-standard Composer setups → "command not found" that reads as user error.
• No rollback — recovery is git reset --hard at best, re-clone at worst.

Mitigations are cheap and should be mandatory acceptance criteria for any pilot: enforce clean working trees, add a target-framework pre-flight check, and document the recovery command in the README.

Ramp-up. Half a day for a Laravel-fluent developer to grasp the provider/command/stub pattern; two to five days to fork, validate, and document. Low individual learning curve, but institutional knowledge concentrates in one or two people unless the fork is documented deliberately — a bus-factor risk worth naming in the go/no-go.

Verdict. Do not adopt as a dependency. Approve a short, time-boxed internal fork only if the fleet contains multiple Laravel 5.x applications still using the preset workflow and no near-term upgrade is planned. Otherwise, reimplement the same scaffolding outcome as a composer create-project template, archive this evaluation, and redirect the effort to the maintained equivalents (Breeze/Jetstream/starter kits). The 0.275 score is an accurate read: low maturity, low validation, and a decaying technical foundation — usable as a blueprint, not as a product.