Skeleton Laravel Package

Product Decisions This Supports

• Standardization of build processes for Laravel/PHP projects where teams lack consistency in deployment, linting, or dependency management tasks. The package provides pre-configured Phing targets (e.g., phpunit, gitignore, composer:audit, and now the consolidated check targets) that can be adopted to enforce uniformity across projects, reducing onboarding time for new developers.
• Dependency hygiene and supply-chain gating — v2.33.0 adds the ability to check only outdated dependencies (PR #176). This is the first capability in the package with a direct risk story: a cheap, repeatable "are we stale?" gate that can run locally or in CI without pulling in Dependabot/Renovate configuration. Useful as a pre-release checklist item rather than a full dependency-management strategy.
• Accelerate internal tooling development for teams already using Phing, eliminating the need to reinvent common build scripts (Docker setup, code style enforcement, dependency checks). Still a "build vs. buy" win where a custom solution would require significant upfront effort.
• Support for legacy or niche workflows where Phing is preferred over Artisan or Composer scripts (monorepos, hybrid PHP/non-PHP projects). Useful for teams with deep Phing expertise or configurations not covered by Laravel's ecosystem (custom psalm or php-cs-fixer setups).
• Roadmap for CI/CD simplification: a stepping stone for teams moving from manual scripts to automated pipelines, with a later transition to Forge, Envoyer, or GitHub Actions.

When to Consider This Package

• Adopt if:

  • Your team exclusively uses Phing and lacks standardized targets for common tasks (dependency updates, linting, deployment prep).
  • You want quick wins for internal tooling (scaffolding .gitignore, running PHPUnit, checking outdated dependencies) without writing custom scripts.
  • You want a lightweight dependency-freshness check and don't want to adopt Renovate/Dependabot for a small or non-GitHub-hosted repo.
  • You're evaluating low-risk, short-term solutions for non-critical workflows (local dev environments, pre-release checklists).
  • You can absorb a target rename — see the breaking change below — and pin to a specific version.

• Look elsewhere if:

  • Your stack relies on Artisan, Composer scripts, or modern CI/CD (GitHub Actions, Deployer). This package adds complexity to Laravel-native workflows.
  • You depend on the old analysis:* target names. v2.33.0 renames analysis targets to check; any existing phing.xml, CI job, or docs referencing the previous names will break on upgrade. Budget migration work or pin to v2.32.x.
  • You require enterprise-grade support, security audits, or vendor SLAs. Development is active but it remains a single-maintainer project with no dependents — bus-factor risk is unchanged.
  • Your team lacks Phing expertise—integration requires familiarity with Phing's XML syntax and build files.
  • You need advanced features (multi-stage deployments, dynamic environment configs) not covered by the package's static targets.
  • You have unresolved concerns about repository provenance — verify the source (typosquatting, fork lineage) before adoption, as with any low-adoption package.

How to Pitch It (Stakeholders)

• For Executives:

  "This is a lightweight way to standardize repetitive build tasks across our PHP/Laravel projects, potentially saving 1–3 engineer-days per project by eliminating custom script development. MIT license, no licensing risk, and it now includes a dependency-freshness check that gives us an early warning on stale libraries. The project is actively maintained — two merged PRs in the latest release — but it's still a single-maintainer, low-adoption package. We'd treat it as a temporary, internally-owned solution: only for internal, non-critical workflows, only if it accelerates a specific initiative (e.g., onboarding new developers), and only with a named owner who can maintain or fork it."

• For Engineering Leaders:

  *"jawira/skeleton provides pre-built Phing targets for PHPUnit, .gitignore management, Composer audits, and dependency-outdated checks. For teams already on Phing, it removes boilerplate and enforces consistency. Two things changed in v2.33.0: analysis targets were renamed to check (a breaking change if we're on it anywhere), and there's a new check that flags only outdated dependencies. Recommendation:

  1. Pilot in a single project, pinned to an exact version.
  2. Avoid it for production pipelines — use Forge/Envoyer or GitHub Actions there.
  3. Fork it if adopted, so a target rename upstream can't break our CI, and we can add Laravel-specific targets. The real question is: Does standardizing these tasks justify owning an unproven package? The rename in this release is exactly the kind of churn we'd be signing up to absorb."*

• For Developers:

  "Run phing phpunit, phing gitignore, or the new check targets instead of rewriting the same build scripts per project. Useful if your team is on Phing and wants a shared baseline. Before upgrading: v2.33.0 renamed the analysis targets to check — update any phing.xml, CI jobs, or docs that reference the old names. The new outdated-dependency check is genuinely handy as a pre-release step. Caveats: not Laravel-native (Phing, not Artisan), single maintainer, low adoption. Use it for local dev and internal tools, not production. If you adopt it, fork it — you'll want to add artisan:migrate-style targets anyway, and a fork protects you from upstream renames."