Package Skeleton Laravel Laravel Package

Technical Evaluation

Architecture fit. zingimmick/package-skeleton-laravel is not a runtime library — it is a Composer/Laravel package scaffolding template used at the inception of a new package repository. It shapes the project layout, composer.json constraints, static-analysis and formatting config, PHPUnit setup, and the GitHub Actions CI matrix. Architecture fit is therefore a governance/standards question, not a runtime one: adopting it means adopting its opinions about how Laravel packages should be structured and tested. 3.5.0 expands the supported matrix to Laravel 13, PHP 8.5, and PHPUnit 12, and realigns the orchestra/testbench constraint — i.e. it tracks upstream Laravel release cadence, which is the primary value proposition of a maintained skeleton.

Integration feasibility. Low technical effort, non-zero process effort. There is no code path to wire into our services; a team runs composer create-project (or clones/forked-remote) once per new package and then owns the generated code outright. The real integration work is template distribution and drift control: how teams obtain the skeleton, what version they pin, and how CI/config improvements from upstream reach packages that were generated months ago. The release itself contains no behavioural changes — every entry is either CI action bumps (setup-php, actions/checkout, ramsey/composer-install), a license year tick, or test-matrix support additions.

Technical risk. Moderate and concentrated in version skew rather than defects:

• The new support claims (Laravel 13, PHP 8.5, PHPUnit 12) are forward-looking. Generated packages may be scaffolded against versions we do not yet run in production or CI, producing either false confidence or immediate constraint edits.
• The orchestra/testbench constraint change (PR #176) is the most consequential line item: testbench majors are coupled to Laravel majors, so a relaxed or shifted constraint can silently determine which Laravel versions a generated package can be tested against.
• Upstream is effectively single-maintainer with heavy dependabot traffic; the 3.4.0→3.5.0 delta is ~18 PRs of which ~13 are automated bumps. That is a good sign of hygiene and a weak signal of human review depth on the parts that matter.
• Skeleton upgrades are one-way: once generated, there is no supported merge path. Stale scaffolding is the dominant long-term risk.

Key questions.

1. Which Laravel/PHP versions are our currently supported baseline, and does a generated package targeting Laravel 13 / PHP 8.5 break our CI?
2. Do we consume the skeleton as a pinned tag, a vendored fork, or an internal generator that layers our own conventions on top?
3. Who owns the fork/template, and on what cadence do we absorb upstream changes?
4. Does our test tooling already run PHPUnit 12, or would generated packages require a second runner?
5. Is single-maintainer upstream acceptable for a repo-shape dependency, and what is our exit path if it stalls?

Integration Approach

Stack fit. Good for a PHP/Laravel organisation standardising package shape: it encodes Laravel-idiomatic conventions (Pint, PHPStan, PHPUnit, testbench, GitHub Actions) that would otherwise be re-litigated per package. It is a poor fit for teams not on GitHub Actions, or on teams with an existing internal package template — adopting both creates two competing gold paths.

Migration path. Do not retrofit. Existing packages stay as-is; the skeleton applies to new packages only, with CI/config improvements cherry-picked by hand where valuable. Concretely: fork or mirror at tag 3.5.0, add our org-level layer (LICENSE holder, CODEOWNERS, security policy, required workflows, PHP/Laravel constraint floors, internal namespace/author defaults), and publish that as the canonical entry point.

Compatibility. Validate generated output against our real matrix before rollout — at minimum, generate one throwaway package and confirm it installs and tests green on each Laravel/PHP combination we actually support. Treat the Laravel 13 / PHP 8.5 support as available, not default: pin the generated composer.json and CI matrix to our supported floor rather than inheriting upstream's maximum. Confirm the new orchestra/testbench constraint resolves cleanly alongside our locked Laravel versions.

Sequencing.

1. Pin 3.5.0 in the internal mirror; do not track 3.x floating.
2. Layer org conventions and narrow the support matrix to our baseline.
3. Pilot with one team on one non-critical new package.
4. Publish the generator/template and a short "how to start a package" doc.
5. Establish a quarterly upstream-review cadence, with an explicit trigger for security-relevant or Laravel-major-support releases.

Operational Impact

Maintenance. Ongoing cost is owning a thin fork: absorbing upstream diffs, resolving conflicts against our org layer, and periodically re-validating generated output. Upstream's dependabot volume means the diff is noisy but the semantic surface is small — expect a few hours per quarter, more when Laravel ships a major.

Support. Low. Failures surface at scaffold time in a developer's terminal, not in production. The support conversation is "which template version did you start from," so version-stamping generated repos (a TEMPLATE_VERSION marker or PR template note) is worth the small effort. Escalation path is the template owner, not an on-call rotation.

Scaling. Effectively free — usage is proportional to new-package count, not traffic or data volume. The scaling concern is organisational: divergence grows with the number of teams unless the template is the only sanctioned start path and is reviewed like any shared dependency.

Failure modes.

• Silent staleness: packages generated from an old tag carry outdated CI and dependency constraints, and nobody notices until a build breaks or a CVE lands.
• Matrix drift: generated packages claim support for Laravel 13 / PHP 8.5 that our platform cannot actually verify.
• Upstream stall or abandonment: single-maintainer project; our fork must remain independently viable, which the fork strategy already mitigates.
• Template sprawl: teams copy-paste an old generated package instead of the template, reintroducing the drift the template was meant to remove.
• Constraint collisions: an inherited orchestra/testbench or PHPUnit constraint conflicting with our pinned test tooling.

Ramp-up. Near-zero for any PHP developer — it is a create-project and a README. Budget roughly half a day for a developer's first pass through the org-specific conventions (namespace defaults, required workflows, constraint floors) and about a day for the template owner to produce and validate the internal layer. Document the "start from the template, not from an old package" rule explicitly; that single line prevents most of the failure modes above.