Tooly Composer Script Laravel Package

Product Decisions This Supports

• Distribution strategy for CLI/ops tooling. If any part of the product surface is a command-line tool (an installer, a migration/seeder runner, a deployment or scaffolding CLI for Laravel projects), this package turns "how do we ship a single-file executable?" into a Composer-script configuration problem rather than a bespoke build pipeline. That is a packaging decision with real support-cost implications: a PHAR means customers/teammates need no Composer, no vendor directory, no PHP extension archaeology.
• Build vs. buy for internal release tooling. The alternative is hand-rolling php -d phar.readonly=0 build.php plus archive/cleanup logic in CI, or adopting a heavier toolchain. This is the "buy a small, opinionated wrapper" option: declarative PHAR definition living in composer.json, invoked through standard composer script hooks so it composes with whatever CI you already run. The decision it informs is whether the release pipeline is code you own and maintain or configuration you declare.
• Roadmap sequencing for developer-experience work. Concretely: "Do we invest a sprint in a one-command install for the CLI, or keep documenting git clone && composer install?" Quantify with support-ticket volume and onboarding time for new engineers or integrators. If the CLI is a paid/partner-facing deliverable, distribution polish is a differentiator; if it is five internal users, it is not.
• Use cases worth naming explicitly: Laravel-adjacent artisan-style utilities distributed to non-developers; QA/audit scripts run on client machines where you cannot assume a PHP toolchain; static-analysis or refactoring helpers shared across teams; bootstrap installers for a larger application.
• What it does not decide. This is developer tooling, not a runtime dependency. It should never appear in require for a customer-facing Laravel application, and it has no bearing on feature-level product decisions. Treat it as infrastructure for the delivery of tooling, not as a capability you build features on top of.

When to Consider This Package

Reasonable fit when all of the following hold:

• You are already shipping, or have committed to shipping, a PHP CLI as a PHAR — this is a prerequisite, not an outcome of adopting the package.
• Your build already runs through Composer scripts and you want the packaging step to be one more hook rather than a separate system.
• The artifact is internal or low-blast-radius: developer tooling, CI helpers, an installer whose failure mode is "run it again," not a customer-facing binary.
• You are willing to pin the version (composer require --dev tm/tooly-composer-script:<exact>) and accept that you may need to fork or patch it.
• You want minimal configuration surface and are comfortable with the author's tooly conventions for declaring PHAR contents in extra.

Look elsewhere — or do not adopt — when:

• Maintenance risk is disqualifying. History is one release in June 2019, then a single patch (1.4.1) fixing checksum generation; 103 stars, zero dependents. One bugfix after a multi-year gap is not a maintenance signal — there is still no downstream ecosystem to surface breakage, no community patches, and no evidence that PHP 8.x or Composer 2 behavior has been validated. Before adopting, spend a half-day verifying it runs on your target PHP and Composer versions; if it does not, the cost is a fork you now own, which usually erases the time saved.
• You need active security response. A single-maintainer, effectively dormant build tool in your release pipeline is a supply-chain surface. If your org requires maintained dependencies or SBOM/vulnerability response SLAs, this fails review on principle.
• You need PHAR hardening. Modern PHAR distribution typically wants scoping/prefixing of vendored dependencies to avoid class collisions, reproducible builds, compression control, signature configuration, and correct checksums. The 1.4.1 patch shows checksum generation has been wrong in past releases — so any artifact built with an earlier version should be re-verified, and if you need integrity guarantees as a standing requirement, pick tooling with a maintainer.
• You are on a modern Laravel stack. Nothing here is Laravel-specific, and a Laravel app gains little; the value case only appears when you are distributing a binary.
• You would be adopting it speculatively. If no PHAR exists today and none is on the roadmap, this is a tool in search of a problem — do not add it "for later."

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, free (MIT), single-purpose build utility that automates packaging a PHP command-line tool into one distributable file. It is not a customer-facing component, carries no licensing cost, and touches only the release process. The strategic question it serves is whether we ship our CLI as a one-file download — which measurably reduces install friction and support load — or require users to manage a PHP toolchain themselves. My recommendation remains a timeboxed spike, not adoption: there was one release in 2019, then nothing until a single checksum bugfix, and the package still has no downstream users. A lone patch is not a maintenance commitment. We should prove it works on our PHP and Composer versions before it enters the pipeline, and we should be prepared to replace it with maintained tooling or a ~2-day in-house script. Worst case the spike costs a few days and produces a decision document; it does not put production at risk.

For engineering — the practical case. A PHAR build is fiddly: phar.readonly, file manifests, excluding dev dependencies and tests, deterministic output, versioning. This package makes that declarative — the archive definition lives in composer.json and runs as a Composer script, so it slots into existing CI with no new orchestration. The trade-off is explicit: we inherit an unmaintained dependency that just shipped its first change in years, and that change is a checksum fix — meaning artifact integrity metadata produced by older versions was unreliable. So gate it — pin the exact version, keep the packaging step behind a single script target so it is swappable, add a smoke test that executes the built PHAR and asserts exit codes and --version, and explicitly assert the PHAR checksum/signature in that test rather than trusting it. Set a review date. If the spike fails on PHP 8 or Composer 2, the fallback is a small owned build script; size that as the true cost of this decision, because that is what we are really choosing between. Do not put this in require; it is require-dev only, and it should never ship inside the artifact it builds.