Skeleton Laravel Package

Getting Started

This package provides a minimal Phing setup intended to be included as a dependency to bootstrap standard build targets. Since it’s lightweight (1 star, 20.165 score) and last released in 2026 (future-dated, possibly placeholder), assume it’s experimental or a personal utility. Start by adding it via Composer:

composer require --dev jawira/skeleton

Then create a minimal build.xml in your project root that imports the provided targets:

<project name="my-project" default="build">
  <import file="vendor/jawira/skeleton/build.xml" />
</project>

Your first use case will likely be running phing to execute a predefined build, test, or clean target — the exact targets are defined in the included build.xml.

Implementation Patterns

• Inheritance via <import>: Skeleton provides reusable targets (e.g., build, test, phpcs, phpstan), but doesn’t enforce structure. Override them in your build.xml by redefining with same name after the <import> — Phing uses last-definition-wins.
• Configuration via properties: The package likely defines properties like build.dir, src.dir, tests.dir in its build.xml. Override them in your build.xml or via -D flags:

  phing -Dbuild.dir=dist -Dsrc.dir=lib
  

• Extensibility: Since it’s minimal, most value is in standardizing DevOps workflows — you extend by adding project-specific targets that call its targets (e.g., build:local calls build + add asset compilation).
• Team consistency: Intended for repeat use across multiple projects — maintain your own build.xml base and share via private Git or local symlink.

Gotchas and Tips

• No autoloading: Phing targets are not Laravel-specific — this is pure Phing, so assume no service container, no Laravel helpers. Everything is XML and shell commands.
• Future release date: The 2026 release date may indicate an uncommitted draft or placeholder; verify actual contents by inspecting vendor/jawira/skeleton/build.xml.
• No config file: Unlike Laravel’s phpunit.xml or rector.php, this package likely relies on CLI props or build.properties — define a build.properties for sanity.
• Debugging: Use phing -verbose to trace target resolution and property substitution. Check phing -list to see which targets are actually available after import.
• Versioning risk: With 1 star and low score, maintainers may not support breaking changes — pin to exact version and vendor build.xml if critical.
• Extension points: Look for hooks like pre-build, post-test — if the skeleton supports them, they’ll be defined with <antcall> or <if><available> blocks. Otherwise, write wrappers that chain targets manually.