Skeleton Php Laravel Package

Technical Evaluation

Architecture fit

• nunomaduro/skeleton-php is not a runtime library — it is a repository template for bootstrapping new PHP packages. It sits at the developer-tooling / "golden path" layer of the architecture, not in the application dependency graph.
• Consequently it has zero runtime coupling: no autoload footprint, no transitive dependency surface, no version-constraint conflicts with Laravel or application code. That is its primary architectural virtue.
• It fits organizations that already standardize on Composer + GitHub Actions + a static-analysis gate. It does not fit shops with an established internal scaffold, a monorepo, or non-GitHub CI without adaptation.
• Treat it as a reference implementation to fork, not as a package to require. The dependents: 0 figure is not a weakness signal — it is confirmation that the artifact is consumed by cloning, which is exactly the intended shape.

Integration feasibility

• Effort is measured in hours, not sprints: composer create-project or GitHub "Use this template", strip author-specific branding, align tooling versions to org policy.
• Prerequisites are modest and likely already satisfied: PHP 8.x, Composer 2, a CI runner. No database, no service dependency, no secrets beyond standard CI tokens.
• The real work is policy alignment, not engineering: PHPUnit major version, PHPStan level, Pint vs. PHP-CS-Fixer, license headers, package naming conventions, and CI workflow hardening (pinned action SHAs, least-privilege GITHUB_TOKEN).

Technical risk

• Overall risk: low-to-moderate. No production blast radius, but meaningful process risk if adopted carelessly.
• Template drift: it is a personal skeleton with no semver contract and no upgrade path. Once forked, you own it entirely; upstream changes will not reach you automatically.
• Opinionation mismatch: the defaults reflect the author's workflow. Adopting them wholesale can fork your engineering standards rather than unify them.
• Supply-chain surface: the generated CI workflows and dev-dependency pins become a recurring attack/obsolescence surface across every package you spawn from it.
• Misuse risk: a contributor may add it as a require-dev dependency instead of a template, producing a meaningless dependency and confusing future audits.
• The 997 stars and 7.155 score indicate a well-regarded reference, but popularity here is a quality signal for the template, not evidence of fitness for your org.

Key questions

1. Do we already have an internal scaffold? If yes, is this a replacement or a source of ideas to backport?
2. Which PHP versions and PHPUnit majors must generated packages support, and does the template's matrix match?
3. Who owns the fork, and what is the cadence for absorbing upstream changes and security patches?
4. Does our dependency policy correctly classify this as tooling (allowed) rather than a runtime dependency (disallowed)?
5. How many new packages do we realistically create per year? Below ~3, the ROI is marginal.

Integration Approach

Stack fit

• Strong fit for Composer-based Laravel/PHP shops on GitHub. The generated structure (src/, tests/, static analysis config, CI workflow, LICENSE, README) maps cleanly onto conventional package layout.
• Weak fit for GitLab/Bitbucket (CI must be ported), monorepos (path repositories and package-splitting tooling need rework), and teams already on a standardized internal template.
• Laravel-specific packages will need additions the skeleton does not provide: service provider + facade stubs, config publishing, package discovery metadata, and an Orchestra Testbench harness.

Migration path

• Do not retrofit existing packages. Retrofitting creates churn and inconsistent intermediate states for no functional gain.
• Apply to new packages only, starting with one or two low-risk extractions (e.g., a shared value-object or HTTP-client wrapper) as a pilot.
• Once the pilot validates the toolchain, promote the fork to an internal template repository with org-specific defaults baked in and documented as the sanctioned starting point.

Compatibility

• Verify the PHP version matrix against your fleet's minimum supported runtime before pinning; the template's defaults will be newer than a legacy estate.
• Reconcile static-analysis level with existing thresholds — a stricter level than current packages will make the new packages look inconsistent and invite bypass.
• Confirm dev-dependency licenses and Composer plugin permissions are acceptable under policy.
• Check that CI actions are pinned to SHAs and that the workflow does not assume repository-level secrets unavailable to new repos.

Sequencing

1. Fork and pin; record the upstream commit as the baseline.
2. Strip author branding; add org license headers, CODEOWNERS, and security policy.
3. Align tooling versions and static-analysis level with org standards.
4. Harden CI (pinned actions, least-privilege tokens, dependency review, secret scanning).
5. Add Laravel-specific stubs if the target use case is Laravel packages.
6. Publish internal documentation and designate an owner.
7. Pilot on 1–2 packages, then mandate for new work.

Operational Impact

Maintenance

• Upstream provides no support contract and no release cadence. Assume you own the fork from day one.
• Budget roughly 1–2 engineer-days per quarter for tooling bumps, action-version updates, and reconciling upstream improvements — modest, but it must be assigned to a named owner or it will silently rot.
• Every quarter of neglect multiplies across every package generated from the template, converting a cheap maintenance task into a fleet-wide remediation.

Support

• Internal-only support model. There is no vendor, no SLA, and issues are best-effort community traffic.
• Documentation must be written and owned internally; pointing contributors at the upstream README will not answer org-specific questions about naming, licensing, or CI.
• Onboarding cost for a PHP developer is under a day — the conventions are standard and the structure is small.

Scaling

• Marginal cost per additional package is near zero; the value compounds with package count, since consistency in CI, static analysis, and release hygiene is what makes a package portfolio governable.
• Below roughly three new packages per year, the fork-maintenance overhead likely exceeds the consistency benefit — in that range, adopt the ideas and skip the fork.
• Scales poorly across polyglot estates; this is PHP-only by construction.

Failure modes

• Stale template: new packages ship with outdated CI and dependencies, embedding supply-chain debt at creation time.
• Tooling divergence: generated packages drift from existing ones, producing two competing standards and reviewer confusion.
• Classification error: the skeleton is added as a dev dependency, polluting the dependency graph and audit trail.
• Silent abandonment: no owner assigned, upstream diverges, and the fork becomes an unmaintained internal artifact nobody trusts.
• Over-standardization: forcing the author's opinions (formatter, analysis level) onto teams without buy-in drives workarounds and weakens the standard rather than strengthening it.

Recommendation

Adopt as a forked internal template for new package creation, not as a dependency. Fund a named owner and a quarterly maintenance slot. Pilot before mandating. The opportunity score (0.03) correctly signals there is no product to build here — the value is entirely in process consistency, and the decision should be framed as a standards investment rather than a technology adoption.