[RFC] Extract Symfony console related rules and extensions to a separate package

[canvural]

Hello,

Recently I saw on Twitter a Laravel user was complaining about type related stuff in Laravel console commands. And saw that @ondrejmirtes saying Artisan is just a wrapper around the Symfony Console. And suggested phpstan-symfony can be used to analyze the commands better.

So what I want to suggest is to extract all Symfony Console related rules and extension into a new package, so that it can also be used by Larastan. I'd like to avoid requiring the whole phpstan-symfony package there. I think that'd cause issues. Another option is to copy all the related code, but I don't like that solution.

What are your thoughts?

[ondrejmirtes]

Hi, I'd like to understand how Artisan vs. Symfony commands are different, how do getOption and getArgument calls map to Laravel?

[canvural]

They are not different at all. Laravel commands extend Symfony\Component\Console\Command\Command So getOption, getArguments etc work normally.

Just one thing: There is this "base" class that all user commands extends. But it doesn't do anything too crazy.

[ondrejmirtes]

So in theory Laravel users could install and configure phpstan-symfony and it'd just work for them?

Can you please explain this tweet to me? https://twitter.com/alexfwulf/status/1594685085009301506

[canvural]

Yes, I did not test it, but in theory it should work with the console stuff. Not sure how it'd be with the rest of the stuff.

Can you please explain this tweet to me? twitter.com/alexfwulf/status/1594685085009301506

I don't know what they mean exactly. There is no input method in Laravel AFAIK nor in Symfony 🤷

[ondrejmirtes]

So:

1. There could be a tidbit in Larastan's README that people can install and configure phpstan-symfony in order to have smarter analysis of their artisan commands.
2. Larastan could depend on phpstan-symfony and just configure consoleApplicationLoader so that it's smarter out of the box without any extra configuration needed from the user.

What would be the problems with either of these approaches? I'm just trying to understand what are you trying to achieve and what should be extracted :)

[canvural]

I do not know what phpstan-symfony does with the rules and extensions. So I thought maybe there could be conflicts, or some false positives. Because if people also have the PHPStan extension installer the Symfony extensions and rules will be activated too.

Ok, so first I'll try and see if it all works.

[ondrejmirtes]

So in order to know what to extract and how, we'd have to know what the problems could be, in order to avoid them 😊

My opinion is that you could require whole extension now, in order to learn what problems are there in practice.

But in order to just have smart type inference of options and arguments, that's just a few lines of code, and I don't think it's worth creating an extra package, I don't even know how I'd name it. So you can just copy those lines 😊

[canvural]

This doesn't look like a few lines of code 😄

Anyway, you are right. First I'll test and see if there are any issues with requiring the whole phpstan-symfony

[ondrejmirtes]

Yeah, it might be a pain because if someone installs extension-installer but you also include the same neon files in Larastan's extension.neon, it's gonna crash.

But the part that just infers correct option and argument types is easy to copy. You might not need the extra rules for now.

[canvural]

Okay, from my limited testing (on 2 projects), there doesn't seem to be an issue with requiring the whole phpstan-symfonyAnd console input/argument types works fine.

But like you said I'll just copy some of the classes there. Because I also realized Laravel adds some helper methods, I'd need to add extensions for it anyway.

Thanks for the small brainstorming 👍🏽

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.