Conflict with php-di

Question

Conflict with php-di

hultberg opened this issue 6 years ago · 10 comments

PHP-DI has a CompiledContainer cache and depends on nikic/php-parser, but as this package has replace on nikic/php-parser, that package is never installed when phpstan-shim is installed as a development dependency and having run composer install --no-dev. Composer autoloader fails when loading my app with:

PHP Fatal error:  Class 'PhpParser\NodeVisitorAbstract' not found in /srv/app/vendor/jeremeamia/SuperClosure/src/Analyzer/Visitor/ClosureLocatorVisitor.php on line 17

Fatal error: Class 'PhpParser\NodeVisitorAbstract' not found in /srv/app/vendor/jeremeamia/SuperClosure/src/Analyzer/Visitor/ClosureLocatorVisitor.php on line 17

/srv/app (master ✘)✹ ᐅ composer why nikic/php-parser    
jeremeamia/SuperClosure  2.4.0   requires  nikic/php-parser (^1.2|^2.0|^3.0|^4.0)  
php-di/php-di            6.0.2   requires  nikic/php-parser (^2.0|^3.0|^4.0)       
phpstan/phpstan-shim     0.10.1  replaces  nikic/php-parser (^4.0.2)               
psy/psysh                v0.9.6  requires  nikic/php-parser (~1.3|~2.0|~3.0|~4.0)

/srv/app (master ✘)✹ ᐅ composer why jeremeamia/superclosure
php-di/php-di  6.0.2  requires  jeremeamia/superclosure (^2.0)

I have tried to both 0.10.1 and master branch. For me, this package is unusable in my application.

JanTvrdik commented 6 years ago

Ref #16

Answer 1 · 2018-07-10T12:39:56.000Z

Have you tried installing phpstan/phpstan instead?

Answer 2 · 2018-07-10T12:43:34.000Z

@JanTvrdik That was what I did before, but I wanted to avoid all the extra dependencies and just use a compiled one. If this package provides a PHAR, I thought is was supposed to be self-containing, i.e. not depending on any composer dependency or the autoloader itself?

Answer 3 · 2018-07-10T12:43:43.000Z

Also, if you can't for some reason, try master instead.

Answer 4 · 2018-07-10T12:46:03.000Z

@lookyman As I explained in my OP, the autoloading issues are related to the fact that nikic/php-parser is not in vendor directory at all. There are no problems running phpstan in my case, but my application.

Answer 5 · 2018-07-10T12:48:12.000Z

I know, but there is a (possible, experimental) fix in master for this scenario, which should allow your application to autoload nikic/php-parser from inside the phar.

Answer 6 · 2018-07-10T13:06:13.000Z

@lookyman Did some testing and seems to work in master. Would be nice to have it released. As stated at 0db0041#commitcomment-29593469, we should be seeing a new release very soon.

My testing repository: https://github.com/hultberg/phpstan-shim-test-19
Branches: good a working example, bad not working.

Answer 7 · 2018-07-10T13:21:50.000Z

However, after some more testing. What was the big issue with replacing nikic/php-parser anyway? PHARs are all self-contained files and should not require or conflict with any other autoloader outside of itself. As tested and proved here: https://github.com/hultberg/phpstan-shim-test-19/tree/test-fork

Answer 8 · 2018-07-10T13:31:27.000Z

I’m on a vacation this week and phpstan’s dev-master needs some work around isset and array offsets. After that I’ll release 0.10.2. Hopefully in the next two weeks.

On Tue, 10 Jul 2018 at 15:21, Edvin Hultberg ***@***.***> wrote: However, after some more testing. What was the big issue with replacing nikic/php-parser anyway? PHARs are all self-contained files and should not require or conflict with any other autoloader outside of itself. As tested and proved here: https://github.com/hultberg/phpstan-shim-test-19/tree/test-fork — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGZuM0FQGFoRY437ruSb6HMYwMnn5Cnks5uFKpvgaJpZM4VJUdx> .

-- Ondřej Mirtes

Answer 9 · 2018-07-22T19:53:10.000Z

This should no longer be a problem in 0.10.2.