phar
phar copied to clipboard
Conflict with `vimeo/psalm` prohibits the installation of plugins
Hey there,
most plugins usually require vimeo/psalm
in a specific version.
I wonder if it is possible to actually change conflict
to replace
while using self.version
.
For every psalm release, there is also a version in here.
This way, this component can actually provide vimeo/psalm
in a specific version and also allows plugins to be installed while keeping composer dependency tree up and running.
Thoughts?
Or do you have reasons for explicitly conflicting with vimeo/psalm
?
Plugins which do explicitly depend on vimeo/psalm
:
- https://github.com/psalm/psalm-plugin-phpunit/blob/5a66a0a7c24d1724cda12d950419ca335f2fb873/composer.json#L21
- https://github.com/psalm/psalm-plugin-doctrine/blob/a565804e383b29c499904728e79dd496110d5c66/composer.json#L30
- https://github.com/orklah/psalm-strict-types/blob/cdbc82ed99ad08af1435367f28bc02a20210a8f5/composer.json#L20
- https://github.com/orklah/psalm-not-empty/blob/cf6161f63c229d4672811f58c7a9c77ce44c25e7/composer.json#L18
- https://github.com/orklah/psalm-strict-equality/blob/3c4a0b259ddd6762cb9a4f4ac6afad28ccdf30bc/composer.json#L18
- https://github.com/orklah/psalm-use-constants/blob/919e6988e92a0e34cb4ee42e0347a43681128b0e/composer.json#L18
- https://github.com/orklah/psalm-elvis-begone/blob/36f02361bec97735a1cd4726df0a21aa52240a75/composer.json#L18
- https://github.com/boesing/psalm-plugin-stringf/blob/07fa6bd4adffd6f11591c96c9c7718c8c9ac9f01/composer.json#L17
So I'd say that this is a very common use-case.
@orklah do you know if this repository is maintained by any1?
https://muglug.medium.com/my-incredible-journey-with-php-df45d72ba2a5
Hey! Possibly me, but I have no idea why the conflict was declared and what are the consequences of changing that
I'd say that the conflict was added to avoid confusions when installing vendor/bin/psalm
(from vimeo/psalm
) & vendor/bin/psalm.phar
(from psalm/phar
).
So I think a replace
would suffice. Having this in the composer.json
should work:
{
"name": "psalm/phar",
"description": "Composer-based Psalm Phar",
"license": [
"MIT"
],
"require": {
"php": "^7.1 || ^8.0"
},
"replace": {
"vimeo/psalm": "self.version"
},
"bin": [
"psalm.phar"
],
"config": {
"platform-check": false
}
}
https://getcomposer.org/doc/04-schema.md#replace
Caution is advised when using replace for the sub-package purpose explained above. You should then typically only replace using
self.version
as a version constraint, to make sure the main package only replaces the sub-packages of that exact version, and not any other version, which would be incorrect.
This would actually only replace the same version rather than "any".
The question is, if that would suffice. Depending on how the phar
file is created, the namespace might not be correct anymore. If so, plugins won't work as they implement interfaces of psalms namespace.
Maybe thats another (or the real) reason of why conflict
was used.
Hi @boesing , did you figure out if there are any workarounds that would allow using plugins with phar installation?