Skip to content
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

Open
jtojnar opened this issue Mar 3, 2020 · 7 comments
Open

Plug-ins not compatible with PHAR #2905

jtojnar opened this issue Mar 3, 2020 · 7 comments
Labels

Comments

@jtojnar
Copy link

jtojnar commented Mar 3, 2020

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:

Uncaught InvalidArgumentException: This plugin must extend _HumbugBox12c1ba8963d4\Psalm\Internal\Analyzer\FileAnalyzer - /home/jtojnar/Projects/selfoss/utils/psalm/TemplateChecker.php does not in phar:///home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar/src/Psalm/Config.php:950
Stack trace:
#0 phar:///home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar/src/Psalm/Config.php(917): _HumbugBox12c1ba8963d4\Psalm\Config->getPluginClassForPath(Object(_HumbugBox12c1ba8963d4\Psalm\Codebase), '/home/jtojnar/P...', '_HumbugBox12c1b...')
#1 phar:///home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar/src/Psalm/Internal/Analyzer/ProjectAnalyzer.php(366): _HumbugBox12c1ba8963d4\Psalm\Config->initializePlugins(Object(_HumbugBox12c1ba8963d4\Psalm\Internal\Analyzer\ProjectAnalyzer))
#2 phar:///home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar/src/psalm.php(398): _HumbugBox12c1ba8963d4\Psalm\Internal\Analyzer\ProjectAnalyzer->check('/home/jtojnar/P...', false)
#3 phar:///home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar/psalm(5): require_once('phar:///home/jt...')
#4 /home/jtojnar/Projects/selfoss/vendor/psalm/phar/psalm.phar(14): require('phar:///home/jt...')
#5 {main}
(Psalm 3.9.3@2e4154d76e24d1b4e59e6cc2bebef7790cb9e550 crashed due to an uncaught Throwable)

I cannot install Psalm using the vimeo/psalm package as it has conflicts with one of our dependency’s dependencies.

@weirdan
Copy link
Collaborator

weirdan commented Mar 3, 2020

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

@muglug muglug added the bug label Mar 3, 2020
@filips123
Copy link

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.

@mr-feek
Copy link
Contributor

mr-feek commented Oct 9, 2020

@filips123 this is a very interesting problem -- does anyone know if other development tools with plugins have solved this?

@muglug
Copy link
Collaborator

muglug commented Oct 12, 2020

@mr-feek we'd use the solution in the Phar that PHPStan uses – providing the necessary classes via a bootstrap

@andreasciamanna
Copy link

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.

@weirdan
Copy link
Collaborator

weirdan commented Oct 19, 2020

@andreasciamanna I'd recommend to use bamarni/composer-bin-plugin. This way you'd be able to install Psalm (and plugins, I suppose) into their own separate composer env, so that it won't conflict with your project dependencies.

ktomk added a commit to ktomk/psalm-plugin-wordpress that referenced this issue May 8, 2021
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
ktomk added a commit to ktomk/psalm-plugin-wordpress that referenced this issue May 8, 2021
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
ktomk added a commit to ktomk/psalm-plugin-wordpress that referenced this issue May 8, 2021
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
@almare
Copy link

almare commented Jul 23, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants