The way .ini files are loaded is changing with this commit. Instead of
directly saving which extensions were found, the extensions loaded are
now determined by reading the .ini file.
However, there are some performance concerns here. Perhaps it is worth
*not* reloading the contents of these files unless absolutely necessary.
- Renaming the configuration files from `www.conf` to the backup
(`disabled-by-phpmon`) will now succeed if the `disabled-by-phpmon`
file already exists. This would fail if the `disabled-by-phpmon` file
already existed in previous builds.
- The PHP-FPM alert when there's an issue with a missing socket
configuration file has been tweaked and now contains a workaround if
you want to run a newer version of PHP (e.g. PHP 8.2) that is not
officially supported by Valet yet.
- When attempting to list the PHP version numbers, the `parse()` method
is now used, as opposed to `PhpVersionNumber.make()`, which couldn't
correctly handle pre-release versions of PHP.
- Updated tests to reflect these changes to `PhpVersionNumber`.
It'll be a while before a new release candidate is available, but this
bug has now been resolved.
A new `PhpVersionNumber.parse` method has been added which can throw.
The `VersionExtractor` class is now capable of extracting version
numbers from all strings now too, and isn't just used to determine
the Valet version number.
New tests have been added to handle these scenarios.
This commit also removes the phpmon-cli component, which wasn't being
updated or maintained (it was an experiment).
The version constraint checks will also be used in the future to
evaluate whether any given site's PHP constraint (if set) is
valid for the currently linked version of PHP.
For example, assuming you have PHP 8.1.2 linked, we could evaluate:
* A site requires "8.0" -> invalid
* A site requires "^8.0" -> valid
* A site requires "^8.0.0" -> valid
* A site requires "~8.0" -> valid
* A site requires "~8.0.0" -> invalid
Currently, this constraint check is used to determine which versions
that are currently installed are good suggestions to switch to.
If you have a site with constraint "^8.0" for example, and you have
PHP 8.0 and 8.1 installed (with 8.1 linked), then you will get a
suggestion to switch back to 8.0.
As part of the boot procedure, recommend upgrading Valet if the version
seems to be too old. For version 4.1 of PHP Monitor, the version has
been hard-coded to 2.16.2 (for PHP 8.1 compatibility).
* The information extracted from Homebrew's JSON command now also
includes information about linked keg and installations.
* The mapped versions in the App class now contain information about
the Homebrew installation as well.
* A HomebrewDiagnostics class has been added, which is currently able
to detect conflicts between the `php` formulae of core and the
`shivammathur/php` tap (which is currently an issue, see #54)
* Alerts are now displayed as critical if they are truly problematic.
* PhpInstallation was renamed to ActivePhpInstallation, to make room
for a generic PhpInstallation object which contains cached info.
* Shell.pipe() now returns the contents of standardError if
standardOutput was empty and there was some data in standardError.
This makes it easier to debug the output of commands that output to
standardError. (For example, failed brew commands might.)
* The README has been updated with additional information
* The acknowledgements section has been added to the README
* The php@X.X/opt/bin/php-config binary is now used (#39)
* Extensions are now loaded from all possible .ini files
* PHP Monitor's preferences window can now be triggered via hotkey
* The first nine extensions can be triggered via hotkey
