Feature request: ignore deprecations

[digitall-it]

Upon starting PHPMon, I receive this message

Your Valet version could not be read ('valet --version' failed)

while the output of valet --version was

Deprecated: Return type of Symfony\Component\Console\Helper\HelperSet::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /Users/giancarlo/.composer/vendor/symfony/console/Helper/HelperSet.php on line 104 Laravel Valet 2.18.9

and the output of valet on-latest-version was

Deprecated: Return type of Symfony\Component\Console\Helper\HelperSet::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /Users/giancarlo/.composer/vendor/symfony/console/Helper/HelperSet.php on line 104 Yes

That means that there's a non stopping deprecation in one of the components of Valet, that spits out the message. The message doesn't go away even after reinstalling PHP and Valet from scratch. The Symfony team needs to update that and I already raised an issue both on Valet and Symfony repos, but meanwhile the PHPMon app could be updated to simply ignore those deprecation messages, as they aren't actually errors, just warnings. Another alternative could be to add this case to the documentation, as this may be something confusing to someone, may happen again in the future, and may induce to think that the problem relies on phpmon itself.

[nicoverbruggen]

Aha, good point.

Do you happen to know what dependency is causing this? I'd like to reproduce this with my own global composer setup. Thanks!

(It's quite possible that you have another dependency in your global Composer file that forces an outdated version of symfony/console, in this particular case.)

[digitall-it]

Unfortunately, I am still trying to figure that out, but have some more info gathered while taking a look around
symfony/symfony#42199 (comment)
laravel/valet#1109 (comment)

[nicoverbruggen]

Could you attach the contents of your global composer.json file here (+ lockfile if you can)? You can find both here:

~/.composer

Thanks!

[digitall-it]

{
    "require": {
        "littlegiant/sliver": "^0.1.0",
        "psy/psysh": "@stable",
        "beyondcode/expose": "^2.0",
        "botman/installer": "^1.0",
        "laravel/valet": "^2.18"
    }
}

[nicoverbruggen]

Okay, here we go. Don't know if you know about the why and why-not commands in composer, but they're really cool. Let's see what we can find out:

$ composer why-not symfony/console 4.0
psy/psysh        v0.7.2  requires  symfony/console (~2.3.10|^2.4.2|~3.0)
symfony/console  v4.0.0  requires  php (^7.1.3 but 8.1.2 is installed)

It seems like psysh is the cause. I removed it, but we're still on symfony/console v3.

Let's see why we require psy/psysh:

$ composer why psy/psysh
littlegiant/sliver  0.1.0  requires  psy/psysh (^0.7.2)

Seems like it's down to this package causing you issues. If you remove it (and psysh), you'll find symfony/console gets updated to v4.4, and your problem should be resolved.

{
    "require": {
        "beyondcode/expose": "^2.0",
        "botman/installer": "^1.0",
        "laravel/valet": "^2.18"
    }
} 

Now, you probably don't want to.

For me, working around deprecation warnings can be quite difficult so I'd prefer not to (it might also slow down the parsing of the output if we have to use a regex to remove lines of the output). Instead it'd be better if you disable deprecation notices in your php.ini file ;)

[digitall-it]

Ok I was looking just for the existence of those commands, as I was looking for them and was accustomed to their npm cousins. Yes, everything "clicks" now. I was wondering, global composer installations shares the same versions of the dependancies? What if two installations have incompatible directives? However, I wanted to make this change to README.md but after reading the PR directive preferred to get in touch. The addition proposed is here:

<details>
<summary><strong>PHP Monitor complains that it cannot read Valet version (`valet --version` failed)</strong></summary>

First, try to issue manually a `valet --version` command in your terminal and look after the result. Sometimes there are no errors, but the output may be littered by deprecation warnings. Indeed, as Laravel Valet is installed globally via composer, it may share some dependancies with other software, and those can make composer install an older version of them (`symfony/console` for example) that issue those warnings. 
	
As PHP Mon relies on the output of Valet to be clean, it cannot parse those messages. In that case, you can follow two routes:
	
- Disable warnings in your php.ini file, and you will be good to go
- Try to solve the deprecation warning: a small trick is to check for the deprecation warning's package using the commands `why`and `why-not`. For example if your warning is raised by `symfony/console`, use `composer why-not symfony/console 4.0` to know what package prevents it to update to a more recent version, and then go ahead and remove or raise an issue with that package mantainer
</details>

the result is this

PHP Monitor complains that it cannot read Valet version (`valet --version` failed)

First, try to issue manually a valet --version command in your terminal and look after the result. Sometimes there are no errors, but the output may be littered by deprecation warnings. Indeed, as Laravel Valet is installed globally via composer, it may share some dependancies with other software, and those can make composer install an older version of them (symfony/console for example) that issue those warnings.

As PHP Mon relies on the output of Valet to be clean, it cannot parse those messages. In that case, you can follow two routes:

• Disable warnings in your php.ini file, and you will be good to go
• Try to solve the deprecation warning: a small trick is to check for the deprecation warning's package using the commands whyand why-not. For example if your warning is raised by symfony/console, use composer why-not symfony/console 4.0 to know what package prevents it to update to a more recent version, and then go ahead and remove or raise an issue with that package mantainer

[digitall-it]

ok so I set my error_reporting to E_ALL & ~E_DEPRECATED & ~E_STRICT and my valet --version command is now "clean", without having to uninstall any package (psysh is cool as I use it for non-Laravel projects), but somehow PHP Mon still cannot make it. I suppose it is calling a different version of PHP that I use from the CLI? Is it possible?

[nicoverbruggen]

Thank you for the suggestion, I'll add this to README later!

Which PHP version is linked and which .ini file did you adjust?

(I might need to make an adjustment in the app to fix this in case the .ini file is not loaded correctly)

[digitall-it]

brew link php
Warning: Already linked: /usr/local/Cellar/php/8.1.2
To relink, run:
  brew unlink php && brew link php

php -i|grep php.ini
Configuration File (php.ini) Path => /usr/local/etc/php/8.1
Loaded Configuration File => /usr/local/etc/php/8.1/php.ini

grep "error_reporting" /usr/local/etc/php/8.1/php.ini
; error_reporting
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

php -v
PHP 8.1.2 (cli) (built: Jan 21 2022 04:47:46) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2, Copyright (c), by Zend Technologies

[digitall-it]

/bin/sh --noprofile --norc --login -c 'export PATH=/usr/local/bin:$PATH && sudo /usr/local/bin/valet --version'
Password: *********
Laravel Valet 2.18.9

[nicoverbruggen]

Oh, Valet's asking for your password? Try running valet trust again!

This is a mistake on my part, I try to find out what the Valet version is BEFORE checking if valet trust has done its job.

cat /private/etc/sudoers.d/valet should contain: /usr/local/bin/valet.

[digitall-it]

yes that did it! Didn't know this command existed, valet trust, I'm more of a Sail person! So, as the deprecation warnings did not issue any problem, my FAQ entry is completely wrong!

[nicoverbruggen]

Yes, apparently the regex had no issues with the deprecation warning, so your README changes won't be needed. Thanks to your report I have made sure the order of messages is fixed in the next update.

I hope you find the app useful, and if you do, consider sending me a tip / sponsoring!

Cheers!

[digitall-it]

Thank you, this is the first time that I am seeing it, I am more of a Sail guy and would like to use Valet with other frameworks like Silverstripe but have to understand how it works.. I'll try it out, if I have any use for it I'll surely tip you!