- How do I install clue/phar-composer and build a phar for my Laravel CLI tool?
- The recommended install is as a pinned phar: download a specific release from GitHub, verify its checksum, and bake it into your CI base image so it never enters your dependency graph. You can also use composer require --dev on developer workstations that need the command locally. Then run phar-composer build path/to/your/project; it reads that project's composer.json and bundles the vendor directory with zero additional configuration.
- Can I require clue/phar-composer as a runtime dependency inside my Laravel application?
- No. It is a build-time CLI, and the README explicitly states its source cannot be consumed as a dependency. Architecturally it belongs in the release engineering layer, alongside packaging and artifact publication, never inside your application runtime. It adds no value for FPM or web-service deployments; its fit is distributed PHP CLIs and developer tooling.
- Which PHP, Laravel and Symfony versions does clue/phar-composer support?
- The newest documented support target is PHP 8.1 with Symfony 6, and the tool deliberately supports legacy PHP 5.3 through 8+, with Composer 2 supported since version 1.2.0. There is no Laravel-specific integration, but any Composer-managed Laravel CLI project qualifies because it only consumes composer.json. PHP 8.2, 8.3 and 8.4 behavior is unverified by upstream, so validate against your actual build and target matrix rather than the README claims.
- What is the difference between clue/phar-composer and box-project/box?
- phar-composer is zero-configuration: it takes an existing composer.json, resolves and bundles vendor, and emits an executable phar, and its build argument accepts a project path, a Packagist coordinate or a git URL. Box gives you an explicit configuration file and more fine-grained control over compaction, file inclusion and stub generation. Choose phar-composer for simple, config-free builds and box when you need precise control or an actively maintained alternative.
- Why does my phar build fail because of phar.readonly?
- PHP refuses to create phar archives unless phar.readonly is disabled for the process doing the build. Run the build with php -d phar.readonly=0, or set phar.readonly=0 in the build host's php.ini, and keep that setting strictly on build runners rather than production. Also confirm openssl is available if you need signed phars.
- How do I build a phar from a private git repository with phar-composer?
- The build command accepts almost anything resolvable to a project, including a local path, a Packagist package coordinate, or a git URL, so private repositories work when the build agent has credentials plus git, PHP CLI, Composer and curl installed. Pin a specific tag or commit for reproducible release artifacts and checksum the resulting phar. This makes it practical to package internal tools that are not published on Packagist.
- Does clue/phar-composer work on Windows build agents?
- Build support for Windows was added in version 1.4.0, which also hardened path escaping for shelled-out binaries such as git, php and composer. The install subcommand, which copies the tool to /usr/local/bin using sudo, is not available on Windows, so on mixed fleets use build plus manual placement of the artifact. Environment coupling to those system binaries remains a risk worth testing on each agent image.
- How can I verify that a phar built with phar-composer actually works?
- Execute the generated phar in a clean environment that matches the target host's PHP version, extensions and opcache settings, because build-host assumptions can differ from the target. Check autoload completeness by actually running the commands, since any dependency without an autoload definition is skipped during bundling. Add this smoke test to CI so each release artifact is exercised before publication.
- Is clue/phar-composer still maintained and safe to use for production releases?
- The last release was 2022-02-14 and upstream is a single, sponsorship-funded maintainer, so the material risk is staleness rather than capability. The zero-dependents figure is expected for a CLI but means there is no downstream community pressure to keep it current. It also vendors a fork of the abandoned herrera-io/box v1.6.1, which becomes your code to own if upstream disappears, so pin and checksum releases, consider vendoring or forking on adoption, and keep a fallback such as box or Composer archive plus bin.
- What are the alternatives to clue/phar-composer for distributing a single-file Laravel CLI application?
- Consider box-project/box when you want explicit build configuration, or Composer's bin and archive support when shipping through Packagist is acceptable. Native OS packaging such as container images, deb or rpm packages, or static PHP binaries is often a better fit for internal tools. If you already distribute via Composer or containers, a phar adds little value and this package is likely solving a problem you do not have.