-
Notifications
You must be signed in to change notification settings - Fork 663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plug-ins not compatible with PHAR #2905
Comments
As a workaround you may try https://github.com/bamarni/composer-bin-plugin - it installs packages into isolated composer environments, so they won't conflict with the project deps. TemplateChecker is not exactly working right now, tracked in #2902 |
There is another problem with plugins and Psalm PHAR. Even if they would be compatible, they would basically negate all reasons to use PHARs (resolving dependency conflicts, faster installation time), because they (at least official plugins), require Psalm as Composer dependency. So, even if you installed Psalm as PHAR, plugin will install it again using Composer. In my case, I want to use PHPUnit plugin and have both Psalm and PHPUnit installed as PHARs. I have two problems. First is that Psalm doesn't recognize PHPUnit classes because they are in PHAR (see #3868). Second is that even if loading classes from PHAR is supported in the future, I still won't be able to use plugin, because it would install Psalm and PHPUnit again using Composer. |
@filips123 this is a very interesting problem -- does anyone know if other development tools with plugins have solved this? |
I find myself in a deadlock situation. I can't install Psalm due to a bunch of unresolvable (at the moment) dependency clashing. I can't use the phar version (installed via Phive) because I need to use a Psalm plugin. I can only fix the issues that prevent me from installing Psalm as a Composer package - something I would prefer to avoid to do anyway, as I 100% agree with this statement -, only after fixing some of the issues I would expect Psalm to report. I can't use hackish workarounds either, as I need to provide a clean solution to implement Psalm in 10 different projects (all sharing the same issues) and resolve some of the technical debt our codebase is affected with. I'm monitoring this issue, hoping for a solution. |
@andreasciamanna I'd recommend to use |
Previously paths to dependencies were resolved against the current working directory and the plugin crashed early if the current working directory is different with a RuntimeException making Psalm failing to load the PsalmWordPress\Plugin. This has been tested against a scenario where psalm is available as tools/psalm in the project and the composer.json lies within the tools/ folder. This would also be the case if the vendor directory is not named "vendor" or when installing psalm with the composer-bin plugin (which is sometimes suggested in the psalm project [1]). Fix here is to check for the other packages folders relative to its own package folder in case the original path relative to the current working directory is not a directory. It is done in a way that effectively prevents checking for the name "vendor" for the [vendor-dir] in case it is installed as a package. [1]: vimeo/psalm#2905 (comment) [vendor-dir]: https://getcomposer.org/doc/06-config.md#vendor-dir
Previously paths to dependencies were resolved against the current working directory and the plugin crashed early if the current working directory is different with a RuntimeException making Psalm failing to load the PsalmWordPress\Plugin. This has been tested against a scenario where psalm is available as tools/psalm in the project and the composer.json lies within the tools/ folder. This would also be the case if the vendor directory is not named "vendor" or when installing psalm with the composer-bin plugin (which is sometimes suggested in the psalm project [1]). Fix here is to check for the other packages folders relative to its own package folder in case the original path relative to the current working directory is not a directory. It is done in a way that effectively prevents checking for the name "vendor" for the [vendor-dir] in case it is installed as a package. [1]: vimeo/psalm#2905 (comment) [vendor-dir]: https://getcomposer.org/doc/06-config.md#vendor-dir
Previously paths to dependencies were resolved against the current working directory and the plugin crashed early if the current working directory is different with a RuntimeException making Psalm failing to load the PsalmWordPress\Plugin. This has been tested against a scenario where psalm is available as tools/psalm in the project and the composer.json lies within the tools/ folder. This would also be the case if the vendor directory is not named "vendor" or when installing psalm with the composer-bin plugin (which is sometimes suggested in the psalm project [1]). Fix here is to check for the other packages folders relative to its own package folder in case the original path relative to the current working directory is not a directory. It is done in a way that effectively prevents checking for the name "vendor" for the [vendor-dir] in case it is installed as a package. [1]: vimeo/psalm#2905 (comment) [vendor-dir]: https://getcomposer.org/doc/06-config.md#vendor-dir
I had the same problem. I just added to this repo the plugins I needed. Than I activated them and made a custom build with box compile. I use this now for all my projects. Works for me. |
I tried to use
TemplateChecker
as described in the docs but unfortunately it does not work with Psalm installed as PHAR since it renames the namespaces:I cannot install Psalm using the
vimeo/psalm
package as it has conflicts with one of our dependency’s dependencies.The text was updated successfully, but these errors were encountered: