Is it possible to debug controller actions with Psy\sh?

[m1lt0n]

While developing locally (using Laravel v12.22.1), I needed to debug a controller action, so I added eval(\Psy\sh()); in the relevant place in the code. In the logs (either running composer run dev or php artisan serve), I see some output from Psy shell, but it looks like execution doesn't stop.

Digging a bit deeper, I saw that running directly php -S localhost:8000 -t public properly stops. Checking the command ran by artisan (in vendor/laravel/framework/src/Illuminate/Foundation/Console/ServeCommand.php) I see that the command starts a new process and that process does not set TTY to true. Quickly adding a $process->setTty(true) in the startProcess method of the command, everything works properly with php artisan serve (still not working with composer run dev -I guess because npx concurrently creates a non TTY process on top of the other processes- with an error "TTY mode requires /dev/tty to be read/writable." - this is fixable by guarding before setting the value with isTtySupported)

Is not setting TTY to true for the process on purpose? (eg because of side effects that I'm missing)? Would it make sense to have the serve command have tty be configurable?

Otherwise I guess the main options for debugging controller actions would be setting up Xdebug or using dd to inspect (or stopping php artisan serve and starting the server with php -S .... directly)?

[henzeb]

What are you trying to achieve? What are you debugging?

[m1lt0n]

Usually, when I'm getting wrong results from eg database queries via eloquent, I add a breakpoint and try to see what I'm missing (eg by rewriting the query and dumping the raw SQL, etc), so I'm doing some kind of experimentation/trying out different things.

It's definitely possible to do that with artisan tinker of course, so I may be overthinking it. Another use case is checking the outcome of request validation. For this one, I guess using dd could be enough. I guess opting for a breakpoint may be related to the fact that I have been debugging this way very frequently while working with python codebases (where a breakpoint() call stops execution anywhere - endpoints/scripts etc), so probably it's something I'm very familiar with.