Composer phar releases?

[spaze]

Sometimes, I prefer the phar distribution of various tools, and I know PHPCS creates phars both as release assets and downloadable, and I know there's Phive too, but I still like to manage the versions with Composer.

To mostly scratch my own itch, I have created a phar repository of PHPCS hosted here https://github.com/spaze/phpcs-phar
I also wanted to learn GitHub Actions a bit more, to see if it's possible to do what I intended to do.

I have seen some other PHPCS phar Composer packages (for example), but they seemed to be updated manually, which I wanted to avoid at all cost.

So I've built it completely automated: if PHP_CodeSniffer releases a new version, GitHub Actions workflow will pick it up (in 2 hours latest, can be configured), commit a new version, check if it works, verify the signature and create a new release with the same version number.

You can see the 3.8.1 phar release here https://github.com/spaze/phpcs-phar/releases/tag/3.8.1 I don't need older releases so I'm not planning on back-adding them.

As I said, I've created this to be used by me mostly, but I was wondering whether you'd like to bring it under the PHPCSStandards GitHub organization? It may complement the regular package, similar to vimeo/psalm and psalm/phar packages, it may be useful for some other folks, but may as well not be useful to anyone else, either way I don't really mind :-)

I could help maintain this repo of course, as I'd maintain my repo anyway, but I don't expect much issues or PRs in this particular case.

Things I'd expect to be maintained from time to time, but probably very rarely:

• The PGP key id
• The phpcbf wrapper, the phpcs wrapper is just a require

The phar is downloaded automatically, composer.json is auto-overwritten too (the phar release replaces just the one regular release).

There may be one possibly controversial thing, and that is that the phar release replaces the "dealerdirect/phpcodesniffer-composer-installer" plugin. The reason is that it doesn't work with the phar release package anyway as documented so there's no need to install it.

The advantage of doing it this way, instead of publishing phars to the phar repo from the build action for example, is that it would require zero work in the PHP_CodeSniffer repository, no new tokens, no nothing, unless you'd like the phar Composer package to be created immediately. Personally I don't mind, it's an acceptable compromise for me, and the time-to-release could changed from 2 hours to whatever you'd like.

There's really not much to license (and my repo doesn't contain one currently) but happy to use and/or add BSD-3 licence to follow PHPCS.

Please let me know if it sounds good, and even if it doesn't. Thanks.

[jrfnl]

Hi @spaze, thank you for opening this issue.

The primary reason why packages like Psalm and phpDocumentor release PHAR-based Composer packages is that they have a lot of runtime dependencies, which often cause conflicts with the runtime/dev dependencies of projects using these tools.

That is not the case for PHP_CodeSniffer, which, at this time, does not have any runtime dependencies, though that may change in the future.

I'd already decided that if/when that happens, a PHAR-based Composer package would be needed (and should possibly become the primary), so I'm open to the idea you are proposing.

However, there are some caveats:

1. Disabling the Composer installer package is not acceptable.
   This will lead to extra support requests for maintainers of external standards, while they have explicitly included the Composer installer package to prevent those support requests.
   Yes, this will mean that changes are needed in the Composer installer package, but that's fine. And making those changes would be a pre-requisite.
   There is already an issue open in the repo about using absolute paths instead of relative ones, for instance.
2. Yes, the package would need to be licensed under BSD-3 - and should already be licensed as such, as the code in the package being distributed is licensed as such. You are probably already in violation of the license as things are now by not included it.
3. Like done for this repo, all releases since the 2.0.0 release would need to be tagged and made available.
4. As the package currently doesn't have dependents (yet) (or very few), I would prefer a package rename under the phpcsstandards organisation.

Obviously the workflow and anything else in the repo would need to be reviewed and validated before a repo move as well, but that's a given.

[spaze]

Hi, thanks. My personal motivation for a phar distro is the suboptimal performance of the 9P filesystem as used by WSL2.

I understand there are some blockers, mainly your points 1. & 3. For 2 I have added a license file now (and will plan to do an hour or two of community service for violating the BSD-3 license, sorry for that. Can send pics 😎). 4. sure, that would go hand in hand with the repo move. I have added a warning to the README that the package will cease to exist one day.

[jrfnl]

@spaze 1 is the real blocker. 3 we can sort out with the repo move and probably use some scripting for, along the lines of what I did for #205. Don't worry about that one for now.

For 2 I have added a license file now (and will plan to do an hour or two of community service for violating the BSD-3 license, sorry for that. Can send pics 😎).

Appreciated and I'm sure the community will appreciate it too 😎