Suggest polyfill packages providing an extension when it is missing.

[stof]

Disclaimer: I'm using mbstring as an example here, but this applies to any extension.

When a package requires ext-mbstring and you don't have it, the output currently looks like that:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires PHP extension ext-mbstring * but it is missing from your system. Install or enable PHP's mbstring extension.

To enable extensions, verify that they are enabled in your .ini files:
    - /etc/php/8.2/cli/php.ini
You can also run `php --ini` in a terminal to see which files are used by PHP in CLI mode.
Alternatively, you can run Composer with `--ignore-platform-req=ext-mbstring` to temporarily ignore these required extensions.

Installing the mbstring extension is indeed the best solution in term of performance. However, there is another alternative if you cannot install the extension: installing a polyfill package that provides the API implemented in PHP. For instance, symfony/polyfill-mbstring provides it for ext-mbstring.

The providers-api-url of Packagist works fine for those extension packages. For instance, the list of packages providing ext-mbstring is at https://packagist.org/providers/ext-mbstring.json
So it would be great if Composer could load it and display an alternative solution based on installing a polyfill package.

[stof]

For context, the Symfony packages are currently defining a requirement on symfony/polyfill-mbstring instead of requiring ext-mbstring. There is 2 reasons for that:

• an historical reason: Composer 1 was not properly supporting packages that provide an extension in its dependency solver. It was working only if the package was already installed in the vendor directory. This is solved in Composer 2.
• a DX reason: it makes it easier to install those packages when you don't have the extension installed.

The big drawback of this approach is that it wastes both bandwidth, disk space and some time loading the bootstrapping files (there is no function autoloading so this is not lazy) for all projects that do have the extension installed, which is the recommended setup. This can be solved by the replace trick usable by projects (not by libraries) to mark the polyfill package as replaced thanks to requiring the native extension.

My suggestion would allow solving the DX reason even for packages that require ext-mbstring, allowing to avoid bringing the polyfill in projects that don't need it by switching packages to require ext-mbstring. And it would provide the similar DX improvement when attempting to install any other package that requires ext-mbstring already.

[glaubinix]

I am not sure if this really is an issue, but I guess polyfills currently also help users that run composer update on machines that have more PHP extensions enabled than their production environment. They currently don't notice that they are missing extensions on their production servers because the polyfills hide this.

Can probably be solved by frameworks and libraries recommending to run composer check on deploy once they drop the polyfills from their required packages.

[stof]

@glaubinix if you run composer install as part of your deployment pipeline, Composer will already check that. And if you don't do it, you should indeed run composer check. But that's true even without this proposal of a better error message on failures.

[glaubinix]

Definitely agree with that and I fully support the feature. I just had a feeling that moving away from adding polyfills by default might result in support requests where people suddenly run into broken deployments.