Provide a Composer shim for the PHAR

[TravisCarden]

👋 Hi, there! I like to use PHAR distributions of my Composer dependencies to minimize transitive dependencies. I see that PHPMD provides one, but only via raw download. Would you consider creating a shim package like psalm/phar, phpro/grumphp-shim, or phpstan/phpstan?

[tvbeek]

We are currently working on completing the support for Phive ( https://phar.io/ ) is that an option that can work for you?

If not I'm thinking about the best way to automate this to keep the work for the maintenance team low.

[TravisCarden]

I'm afraid Phive wouldn't work for me. (I couldn't justify adding a whole new package management system to my pipeline for a single dependency when the rest of the problem is already solved with Composer.) I can live without a PHAR Composer library for PHPMD, but I've come to think it should be considered a best practice, and I'm just kind of putting the idea out there a few places where it seems most feasible. In other words, I don't want to project any undue sense of urgency--much less ingratitude. But I'll leave the issue open in case you want to entertain the idea further. Thanks! 🙂

[AJenbo]

I agree this is a good suggestion for how to manage dev tools as there dependencies shouldn't really influence the production portion of dependencies that happens to be shared or conflict with other tools.

Using composer for managing tools means that a project can control it's dependencies rather then using system wide installations which could lead to issues when they are updated with out projects having adjusted to the new versions (new errors detected etc.).

When phpstan made the switch they renamed the original archive to phpstan-src and created a new phar based on with the old name. I'm not sure if that is a viable solution for us but just putting it out there.

[kylekatarnls]

It's feasible with a GitHub Action. Once #1030 is complete, we can add another step to copy phpmd.phar and phpmd.phar.asc and commit them in another repository.

[ravage84]

It seems PHPStan doesn't support shis anymore, the Composer package is abandoned and the repo has been archived by the owner since 09.12.2019.

https://github.com/phpstan/phpstan-shim

[ravage84]

I agree this is a good suggestion for how to manage dev tools as there dependencies shouldn't really influence the production portion of dependencies that happens to be shared or conflict with other tools.

Using composer for managing tools means that a project can control it's dependencies rather then using system wide installations which could lead to issues when they are updated with out projects having adjusted to the new versions (new errors detected etc.).

Actually, these issues is one of the main reasons why you don't use Composer for execution-only CLI tools, e.g. phars.

You use Composer to integrate dependencies with your project whe you need to extend/use them in your code.

[ravage84]

@TravisCarden I understand your reluctance. I prefer to use Composer over anything else for organizing dependencies, even execution-only tools like PHPMD etc.

But using PHIVE is the proper way to do that as it can be used per project, not only system-wide, and still doesn't collide with the sub-dependencies from Composer.

For example, CakePHP stopped fetching PHPStan through Composer and now uses PHIVE:

https://github.com/cakephp/cakephp/blob/87eba5f374b42efc48acffc665e2d4139accc710/.phive/phars.xml#L3
https://github.com/cakephp/cakephp/blob/87eba5f374b42efc48acffc665e2d4139accc710/composer.json#L123-L130

[AJenbo]

It seems PHPStan doesn't support shis anymore, the Composer package is abandoned and the repo has been archived by the owner since 09.12.2019.

https://github.com/phpstan/phpstan-shim

Like I mentioned: "phpstan/phpstan, has switched to a PHAR file. It works the same way as phpstan-shim"