Removed PHAR builds support

[Ocramius]

This also removes all tooling around PHAR builds.

While PHARs have some use for some community members, PHARs:

• do not come with a runtime/environment
• are inherently unsafe, because (even if signed) you are relying on packages downloaded and installed by maintainer who created the .phar file
• do not match your system requirements, which may be misaligned with bundled libraries, since you are relying on the maintainer's ( @Roave / @Ocramius ) selected set of dependencies

There are various ways to install PHP tools that are way better than PHAR, and that are to be endorsed instead.

nix flake

See https://nixos.wiki/wiki/flakes

Nix flakes are completely immutable, stable, fully reproducible, customizable, and come with a full supply chain traceability of all dependencies.

For maximum stability in your builds, use a nix flake. Patches are welcome to turn this package into a nix flake in itself.

composer.json, composer.lock and composer install

If you have an environment, and you want to install this package into it, generate a composer.json and composer.lock at a specific location:

cd path/to/tools
composer require roave/backward-compatibility-check
git add composer.json
git add composer.lock
git commit -m "Managing own locked version of \`roave/backward-compatibility-check\`"

You can then composer install from that directory at any time, and run ./path/to/tools/vendor/bin/roave-backward-compatibility-check.

composer install will verify that your environment is suited for installation.

use a Dockerfile

This approach comes with the same downsides of .phar files, but:

• tooling to scan for vulnerabilities inside docker images exists, and is very much growing
• a docker image comes with the runtime to execute roave/backward-compatibility-check, and you can even run the full test suite before baking the image and calling it "compatible"

[Ocramius]

I should add that I'm removing the tooling also because I'm fed up with coming back to it every few months and finding it broken: given multiple better tools exist, .phar should finally just go away.

[asgrim]

Composer is literally the only phar I use I think, but I know some people do use phar for tools like this. I'm generally okay with this, but with caveat;

• nix is still quite niche, so whilst it might be an acceptable solution for those already using nix, or for those "tempted" to use it, I don't think we should all-in on that solution
• perhaps provide a baked Docker image (like Composer does) with a built phar already in it? That way, we can be clear about the environment that the phar was built with, and if you "extract" the phar from there into your own, you're basically "on your own". I know it doesn't 100% eliminate phar builds, but at least it helps one of the issues mentioned

Conversely to this proposal, an idea to keep phar around;

• Keep the phar build, but run the phar build on EVERY build, not just releases. Save it as an artefact for the build. Then the only difference in a release build is taking the artefact and adding it to the release. At least then we get a sort of early warning system if the build may break.

[drupol]

I couldn't agree more with this!

PHARs are very convenient, but in 2024 if they cannot be reproduced, it's critical.

Therefore, my contribution to this: NixOS/nixpkgs#313907

Once this will be merged, anybody running Nix will have access to roave-backward-compatibility-check by running: nix run github:NixOS/nixpkgs#roave-backward-compatibility-check

[GeeH]

I agree with everything said here. The overhead is not worth the benefit at this point.

[Slamdunk]

At first I've been hesitant about PHPStan's deployment style, but now I like and endorse it: provide a PHAR as a composer package.
To me it's even better than all the solutions proposed in #770 (comment), but I understand that it may be cumbersome to support for small tools.