Add option to run composer global update after switch

[joelhinz]

Hi Nico, love the app as always. :)

For various reasons of really annoying incompatibilities, I find myself having to run composer global update after just about every php switch I make... which is like 5-6 daily at least.

Would it be possible to add a setting like the one for "Auto-restart PHP-FPM" to also always run composer global update after switching? I know it's a bit of an edge case, but I suspect I'm not the only one with it.

Cheers,
Joel

[nicoverbruggen]

I like this idea, and I actually wanted to add this a while ago. I was unsure on how to handle terminal command errors (since the global composer dependencies might not be compatible with the newly linked version of PHP).

Thankfully, in the latest version of PHP Monitor I'm working on, I've made it much easier to check whether running any command returns a particular error code or error message, so this should not be too hard to implement.

This is important because I will need to display a notification or alert if running composer global update failed for some reason.

Filed as #71!

[joelhinz]

Sounds good! Thanks in advance, and looking forward to it. :)

[jacksleight]

Hi, I have a question/idea related to this.

I currently have PHP 8.1 and 7.4 installed. I'd like to have Laravel Pint installed globally, but Pint only works with 8.0+, so if I do that then every time I switch back to 7.4 I get the "Composer detected issues in your platform" error, as Pint isn't compatible.

Once this happens my only option is to quit PHP Monitor, remove Pint, update composer, then restart PHP Monitor. And then re-install Pint after I switch back to 8.1.

I was just wondering if there was a better way to handle this currently? Or if not, perhaps there could be an option to use different global composer.json files for different PHP versions?

[nicoverbruggen]

@jacksleight I recently bumped into this as well. Unless there is a good reason why you can't use it, I'd recommend using the site isolation feature (Valet 3 required!) to avoid issues like this. (And if you need terminal access to an older version of PHP, you can use the helpers I've included with PHP Monitor.)

When using site isolation, you can keep your global Composer dependencies up-to-date while still being able to enforce a lower PHP version constraint for a given site or terminal session (using the helper commands). This is what I have been doing for my projects ever since site isolation was made available in Valet 3.

I have thought about various ways to improve the "global Composer update process" in the past, like:

• Maintaining a separate global Composer file (and cache) per PHP version
• Allowing a whitelist or blacklist for packages with PHP version constraints (i.e. with rules that allows you to say: install global dependency X, but only on PHP 8.0 and newer, for example)

But given that you can now basically bypass this issue by using site isolation, I've not really spent additional time on improving this particular feature, since it would be a lot of work for relatively little benefit.

I'd like to eventually get around to improving this, but my initial thought is that you should try site isolation and see if that works for your particular use case, since I'm not likely to improve this feature anytime soon given the rewrites I'm doing on PHP Monitor 6.

Good luck and let me know if this worked for you, so if other people stumble upon this thread they know what to do!

[jacksleight]

Ah ha! I had thought that site isolation could solve this, but I wasn't aware of those helpers and assumed the CLI issue would make it a big pain. But no, you've already thought of that! 😃 Amazing. I'll give it a go.

Thanks!