Larastan: Support for Lumen framework

[nunomaduro]

Would be good add support to Lumen.

https://medium.com/@rafaelcanical/although-i-agree-with-jan-alfred-richter-this-is-cool-can-this-be-used-with-lumen-projects-also-259b64c3d10c

[goodevilgenius]

I noticed that it states that it depends on laravel/framework. This is probably overkill, and likely the biggest hurdle to Lumen compatibility.

I imagine changing that to illuminate/console (and perhaps a few other needed illuminate packages) would be sufficient, and would allow compatibility with both Laravel and Lumen.

[nunomaduro]

@goodevilgenius I agree with you. Do you mind of prepare a pull request for that? Please take in consideration all the components/classes of Laravel that are already used on the package.

[goodevilgenius]

I don't have the time to go through the larastan code and find which illuminate packages are specifically needed, sadly.

[nunomaduro]

@goodevilgenius Ok! No problem! Let's put the label "help wanted". It may be a good first issue for someone trying to contribute for open source.

[nunomaduro]

How to resolve this issue:

1. Identity the components illuminate used on the package.
2. Include Laravel components on the composer.json instead of the full framework.
3. Test with Lumen locally.

Example before:

    "require": {
        "php": "^7.1.3",
        "phpstan/phpstan": "^0.10",
        "symfony/process": "^4.1",
        "laravel/framework": "5.6.*",
        "mockery/mockery": "^1.0|0.9.*"
    },

Example after:

    "require": {
        "php": "^7.1.3",
        "phpstan/phpstan": "^0.10",
        "symfony/process": "^4.1",
        "illuminate/support": "5.6.*",
        "illuminate/database": "5.6.*",
        "mockery/mockery": "^1.0|0.9.*"
    },

[nunomaduro]

@richardkeep The version v0.2.0 should support Lumen and Laravel Zero. Do you mind of running some tests? I don't use Lumen that much.

[hskrasek]

@nunomaduro We use Lumen at work, I can give it a try this evening and see how it works out.

[nunomaduro]

@hskrasek Thanks! Because I don't have any big app with lumen. 😅

[hartman]

Working pretty nicely, but I have errors on Mixins.php line 71

Class Eloquent does not exist

Which is probably due to some of the laravel ide-helper magic...
I have:

$app->withFacades();
$app->withEloquent();

and my app service provider is including the ide service helper.

I have $app->register(\NunoMaduro\Larastan\LarastanServiceProvider::class); in my bootstrap/app.php because no laravel package auto discovery with Lumen.

[nunomaduro]

@hartman Ok! I will update the readme.

@hskrasek You got news?

[hskrasek]

@nunomaduro Yesterday turned into a meeting and weird production bug day so I haven’t had a chance to play with it. I’m hoping to today

[hskrasek]

So our project has some.. unique constraints due to legacy code dependencies. Because of this I can’t get s good test without doing some overriding of how phpstan handles composer autoloading.

If I can hack around that I’ll be able to give you a better test. And probably a feature request lol

[goodevilgenius]

My project is a pretty standard Lumen project. I'll give it a try tomorrow when I get in to work.

[goodevilgenius]

Added 0.2.4, and registered the service provider in bootstrap/app.php, and it works great.

Unrelated to Lumen, though, I did get a lot of Call to an undefined static method App\Models\Model::withTrashed() on queries to models with SoftDeletes on them. Since it doesn't show that error with things like Model::create, I would've assumed it would work with withTrashed and onlyTrashed as well.

But, as for it working with Lumen, no problems at all. I've been looking for something to help me drop Scrutinizer, and I think this might be the thing. Thanks for the good work.

[nunomaduro]

That's great news! I will update the readme to close this issue! 👍

[hartman]

@goodevilgenius that sounds like #40

I'm still looking for hints as to why it crashes on my usage of the Eloquent facade, if anyone has any ideas, i'd love to hear them.

[luispabon]

I'm getting the following on a lumen project when I run the analyse command:

 ------ -------------------------------------------------------------- 
  Line   app/Repositories/ModelRepository.php                          
 ------ -------------------------------------------------------------- 
         Internal error:                                               
         Run PHPStan with --debug option and post the stack trace to:  
         https://github.com/phpstan/phpstan/issues/new                 
 ------ -------------------------------------------------------------- 

Running with debug, it crashes on that class throwing an EntryNotFoundException at the illuminate container method get, line 613. It cannot find a service for one of the interfaces imported into the ModelRepository class above.

When commenting out the import, analyse finishes correctly. The bizarre thing is that there's another interface just like the problematic one imported on the line after and it doesn't choke on that.

[nunomaduro]

@luispabon What version of larastan are you using ?

[luispabon]

absolutely latest as installed 5 minutes ago

[luispabon]

v0.2.4

[luispabon]

The interface is implemented by several models, same as the other one that doesn't make it crash. Phpstan itself running raw doesn't crash when analysing that class.

[hartman]

I'm still looking for hints as to why it crashes on my usage of the Eloquent facade, if anyone has any ideas, i'd love to hear them.

So this is the Eloquent mixin phpdoc annotation that is added by @barryvdh/laravel-ide-helper

It cannot resolve the mixin, because basically it doesn't know it exists. I'm not even entirely sure if this error is now within ide-helper, or within the class lookup of larastan actually. It doesn't seem like this is easily ignorable, but i added a try catch to getMixinsForClass to ignore the reflection class error. I couldn't figure out a cleaner way to handle this problem.

$mixins = array_filter(
            $mixins,
            function ($mixin) use ($classReflection) {
                try {
                    return (new \ReflectionClass($mixin))->getName() !== $classReflection->getName();
                } catch (\ReflectionException $e) {
                }
            }
        );

Is there a cleaner way ?

[Korri]

@nunomaduro Looks like #155 also has the secondary effect of installing laravel/framework on Lumen projects.

[nunomaduro]

@Korri There is a problem on that? This is a dev dependency.

[Korri]

@nunomaduro Yeah on our app at least, it breaks the app.

Also its affecting my packages way to much, here is the log after requiring Larastan:

Package operations: 7 installs, 2 updates, 24 removals
  - Removing illuminate/session (v5.6.39)
  - Removing illuminate/routing (v5.6.39)
  - Removing illuminate/contracts (v5.6.39)
  - Removing illuminate/log (v5.6.39)
  - Removing illuminate/bus (v5.6.39)
  - Removing illuminate/queue (v5.6.39)
  - Removing illuminate/support (v5.6.39)
  - Removing illuminate/cache (v5.6.39)
  - Removing illuminate/config (v5.6.39)
  - Removing illuminate/container (v5.6.39)
  - Removing illuminate/database (v5.6.39)
  - Removing illuminate/encryption (v5.6.39)
  - Removing illuminate/events (v5.6.39)
  - Removing illuminate/filesystem (v5.6.39)
  - Removing illuminate/hashing (v5.6.39)
  - Removing illuminate/http (v5.6.39)
  - Removing illuminate/pagination (v5.6.39)
  - Removing illuminate/pipeline (v5.6.39)
  - Removing illuminate/translation (v5.6.39)
  - Removing illuminate/validation (v5.6.39)
  - Removing illuminate/view (v5.6.39)
  - Removing illuminate/console (v5.6.39)
  - Removing illuminate/redis (v5.6.39)
  - Removing illuminate/mail (v5.6.39)
  - Updating nesbot/carbon (1.25.0 => 1.34.0): Loading from cache
  - Installing symfony/polyfill-php72 (v1.9.0): Loading from cache
  - Installing symfony/var-dumper (v4.1.6): Loading from cache
  - Installing ramsey/uuid (3.8.0): Loading from cache
  - Installing league/flysystem (1.0.47): Loading from cache
  - Installing orchestra/testbench-core (v3.6.6): Loading from cache
  - Downgrading laravel/framework (v5.6.39 => v5.6.16): Loading from cache
  - Installing orchestra/testbench (v3.6.5): Loading from cache
  - Installing nunomaduro/larastan (v0.3.2): Loading from cache

I will try to debug what is happening, but in the end I'd prefer not to have the whole framework installed for dev, as it would also affect the packages we are able to use, that might break in production.

[Korri]

Ok, after more investigation, the Laravel helpers are being included before the lumen ones (the fact that they are included at all is a big issue as there is quite the discrepancies between Lumen and Laravel on those).

[nunomaduro]

@Korri Any idea how to still support lumen on Larastan?

[Korri]

@nunomaduro The only issue here is orchestra/testbench if there is a way to not make it an hard dependency (only require in when testing a package), that would solve the issue.

[nunomaduro]

@Korri I may have an idea, tomorrow I will code it 👍

[nunomaduro]

No solution so far.

[Korri]

Looks like the only hard requirement is the Orchestra\Testbench\Concerns\CreatesApplication trait, is there a way to replace it with something that is compatible with Lumen and Laravel?

[ian-nisbet]

It works fine with Lumen already.

I only had to add in the Service Provider to bootstrap/app.php
$app->register(NunoMaduro\Larastan\LarastanServiceProvider::class);

and specify the path.storage and path.config
$app->instance('path.storage', app()->basePath() . DIRECTORY_SEPARATOR . 'storage');
// https://github.com/nasrulhazim/lumen-in-laravel/issues/1
$app->instance('path.config', app()->basePath() . DIRECTORY_SEPARATOR . 'config');
// https://stackoverflow.com/questions/38961790/class-path-config-does-not-exist-lumen-5-2

[vojtasvoboda]

@ian-nisbet Could you please write down step-by-step tutorial how to do that with Lumen? Thank you

I'm still getting orchestra/testbench 3.6.x-dev requires laravel/framework ~5.6.34.

[sksethi25]

@nunomaduro Hey, Any update on this guys?

[nunomaduro]

@sksethi25 I haven't work on this. Fell free to propose a solution/pr.

[sksethi25]

@nunomaduro as of now i just forked and moved "orchestra/testbench" into dev dependence and installed forked version with latest Lumen (5.7.7) (Laravel Components 5.7.*) . Registered service provider and ran the command, it worked like a charm.I have now alot of things to fix first,But Two of them of which caught any immediate attention are :

Call to an undefined method Illuminate\Database\Query\Builder::withTrashed()

and

Internal error: Call to a member function connection() on null
Run PHPStan with --debug option and post the stack trace to:
https://github.com/phpstan/phpstan/issues/new

if you have any ideas about these , let me know. i will too try to update on whats causing these.

[nunomaduro]

For the Call to an undefined method Illuminate\Database\Query\Builder::withTrashed() is a duplicated issue, that already exists.

For the second you need to sahre the code where that happens.

[TheLevti]

Seems to break the whole app if you do not install it (production) by using composer install --no-dev.

Whole app fails when reaching the following lines in bootstrap/app.php

$app = new Laravel\Lumen\Application(
    realpath(__DIR__.'/../')
);

[TheLevti]

All I get is just an empty 200 response for any endpoint. Also php artisan then just does nothing.

[j3rrey]

@nunomaduro
Working perfectly fine on my end.
Lumen 5.8

Instructions:

Add this either in bootstrap/app.php or if you have one into the AppServiceProvider:

$app->register(\NunoMaduro\Larastan\LarastanServiceProvider::class);
$app->instance('path.storage', app()->basePath() . DIRECTORY_SEPARATOR . 'storage');
$app->instance('path.config', app()->basePath() . DIRECTORY_SEPARATOR . 'config');

[TheLevti]

Does your app work if you install with ---no-dev?

[j3rrey]

Does your app work if you install with ---no-dev?

Well I have a production switch, so I assume yes.
Since it's in my dev requirements it won't be installed.

[TheLevti]

Thought so the same, but apparently it does not work for me. I also have it in the dev requirements. Just wanted to ask if someone else tried it.

[j3rrey]

@TheLevti
hmm in that case, how are you registering the service provider and what's the error?

[j3rrey]

@TheLevti try to do a composer dump-auto after your initial composer install --no-dev

[sudomabider]

Surprised no one else has mentioned @vojtasvoboda 's problem yet.

    "require": {
        "php": "^7.1.3",
        "symfony/process": "^4.2",
        "phpstan/phpstan": "^0.11.8",
        "orchestra/testbench": "^3.6",

orchestra/testbench requires laravel/framework and is causing problems with installing in Lumen. Why is orchestra/testbench required at runtime anyway? As far as I can see it's only used in tests (plus an unused import in ApplicationResolver.php which probably shouldn't be there). Moving orchestra/testbench to require-dev should allow us to proceed further with Lumen. Or am I missing something here?

[goodevilgenius]

@sudomabider I noticed. I removed larastan from my project on our last upgrade because of that.

But that's more of a testbench issue than a larastan issue.

[nunomaduro]

https://github.com/nunomaduro/larastan/issues/295

[nunomaduro]

It's fixed on the master branch. The fix will be deployed on the 4.0 version.