clue/phar-composer
phar-composer turns any Composer-managed PHP project into a single executable phar, automatically bundling dependencies and the vendor directory with zero extra configuration. Build from a project path or search Packagist packages interactively—ideal for distributing CLI tools.
Architecture fit. clue/phar-composer is a build-time CLI, not a runtime library — the README explicitly states source cannot be consumed as a dependency. Architecturally this is a release engineering tool: it consumes a project's composer.json, resolves and bundles vendor/, and emits a single executable .phar. It should sit in the CI/CD layer alongside packaging and artifact publication, never inside the application runtime. Fit is strong for distributed PHP CLIs (developer tooling, internal utilities, ops scripts) and essentially zero for FPM/web-service deployments where phars add no value.
Integration feasibility. High. Zero-configuration is the core selling point: one command (phar-composer build <path|package|git-url>) produces an artifact, and it works from a local path, a Packagist coordinate, or a git URL — the last being useful for private repositories. Build agents need PHP CLI, Composer, git and curl. The self-contained phar distribution means the tool itself can be pinned by download + checksum rather than resolved through our dependency graph, which simplifies supply-chain control.
Technical risk. The material risk is staleness, not capability. Last release is 2022-02-14; the newest documented support target is PHP 8.1 and Symfony 6. Composer 2 is supported (since 1.2.0), but current Composer 2.x and PHP 8.2/8.3/8.4 behavior is unverified by upstream. Secondary risks: it shells out to system binaries (git, php, composer) — path escaping was hardened in 1.4.0, but this remains an environment-coupling point; it vendors a fork of the abandoned herrera-io/box v1.6.1 (StubGenerator, Extract), which is now our code to own if upstream disappears; and phar production has inherent constraints (build-time phar.readonly=0, signature/openssl availability, opcache and extension assumptions differing between build host and target host). The 0-dependents figure is expected and benign — nothing should depend on a CLI — but it also means no downstream community pressure to keep it current.
Key questions.
openssl guaranteed on build runners?box-project/box, Composer's bin + archive, or native OS packaging?Stack fit. Any Composer-managed PHP project qualifies, and the tool deliberately supports legacy PHP 5.3 through 8+ so a heterogeneous internal estate can standardize on one build step. Best fit: internal CLI tools and developer utilities where a single downloadable executable removes install friction. Poor fit: long-running services, anything requiring extensions not present on target machines, and anything already distributed as a container.
Migration path. Prefer the pinned-phar installation over composer require --dev for reproducibility — download a specific release, checksum it, and bake it into the CI base image. Only fall back to require-dev where developer workstations also need the command locally. Migration is additive: existing release jobs keep producing their current artifacts while the new phar job runs in parallel for a defined bake period.
Compatibility. Validate against our actual matrix rather than the README claims: PHP version at build time and at target time, Composer major/minor, and Symfony Console range (2.5–6). Note the install subcommand (which copies to /usr/local/bin via sudo) is unavailable on Windows — on mixed fleets, use build plus manual placement; build itself gained Windows support in 1.4.0. Any package in the dependency tree without an autoload definition is skipped, so verify the bundled phar's autoload completeness by executing it, not by inspecting the archive.
Sequencing.
--version and one real command, including from a path containing spaces.Maintenance. Low steady-state effort if pinned; the workload is not "maintain the tool" but "track whether it still works on our PHP baseline." Upstream cadence is slow and single-maintainer, so budget a periodic compatibility spike (one to two days per PHP minor) or a decision point to fork. Record the vendored herrera-io/box derivation in our license/attribution inventory.
Support. Minimal runtime support surface — the tool never runs in production, so failures appear as CI job failures, which is the best possible failure location. The real support risk is knowledge concentration: one or two engineers understand phar quirks (stub generation, signatures, phar.readonly). Write the runbook early.
Scaling. Build cost scales with dependency count and network fetch time from Packagist/git, not with our traffic; it parallelizes naturally across CI runners. Artifact size grows with bundled vendor/, so phars can become large for dependency-heavy projects — set a size ceiling and review. Watch for CI egress policy blocking Packagist or git, and pin Composer versions in the build image to avoid resolution drift between runs.
Failure modes. phar.readonly=0 not enabled at build time; missing or unescaped git/php/composer binaries on the runner; PHP version mismatch between build host and target host producing a phar that builds but won't execute; absent openssl when signing; autoload omissions for odd dependency layouts; rename failures on slow network drives (addressed in 1.4.0 but still a signal for filesystem assumptions); Windows install unavailability. Each has a cheap pre-flight check — add them to the CI template once.
Ramp-up. Developers: near-zero, it is one command with no configuration. CI/release engineers: roughly a day to learn the phar-specific failure modes and pinning discipline. No API or library surface to learn, which keeps onboarding cost low and makes this a low-blast-radius adoption — appropriate given the package's modest maturity signals and 2022-era release cadence.
How can I help you explore Laravel packages today?