I am entirely unsure why one would need these, but I figured I'd get
these in the app before I start the work on PHP Monitor 6.0.
This ensures all common version constraints can now be parsed correctly.
I am entirely unsure why one would need these, but I figured I'd get
these in the app before I start the work on PHP Monitor 6.0.
This ensures all common version constraints can now be parsed correctly.
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.
