Add required extensions and libraries to composer.json

[dingo_d]

Composer offers a way to require or suggest certain platform packages: ​https://getcomposer.org/doc/01-basic-usage.md#platform-packages
Ticket 48081 addresses the PHP version, and this one covers the required libraries and extensions.

I've used the WP-CLI ext package (​https://github.com/johnbillion/ext) to generate all the required and suggested extensions and libraries.

[jrf]

Hi @dingo_d Yet another great step towards the future!

I've reviewed your patch and have two remarks:

1. Please undo the update to the PHP_CodeSniffer package in the composer.lock file. There is an issue with a particular sniff which is why this update hadn't been done yet - see #47632 for more details.
2. IIRC adding the lib-... requirements is only useful when you actually add versions to them. Otherwise, set the ext-... with * instead (for those extensions which are not part of the PHP core).

[dingo_d]

IIRC adding the lib-... requirements is only useful when you actually add versions to them. Otherwise, set the ext-... with * instead (for those extensions which are not part of the PHP core).

So I should just put those libraries to ext- and use wildcard, or remove them entirely (they seem to be required)? Not sure if there will be any negative impact for that.

Also, I'll exclude the lock update, but I'm unsure if this will cause any failures because composer validate complains about them not being up to date with the changes.

[dingo_d]

Updated the patch to only include the composer.json

[johnbillion]

Related discussion on roots/wordpress: ​https://github.com/roots/wordpress/issues/12

[jrf]

Also, I'll exclude the lock update, but I'm unsure if this will cause any failures because composer validate complains about them not being up to date with the changes.

I think you do need to include an updated composer.lock with this change. Just run composer update --lock to only update the hash and not update dependencies.

So I should just put those libraries to ext- and use wildcard, or remove them entirely (they seem to be required)? Not sure if there will be any negative impact for that.

Yes. If they are extensions which are part of the PHP core which cannot be disabled and PHP cannot be explicitly compiled without them, leaving them out is fine.

Note: I have not checked the extensions listed. It looks very long to me - definitely compared to what's in Site Health.

[ocean90]

Related discussion: https://core.trac.wordpress.org/ticket/23912#comment:27

[jrf]

Related ticket to update the list in Site Health: #47454

[dingo_d]

Ok, so for now, the best course of action is to get a confirmed list of required and recommended list of extensions needed. I also like the descriptions in this patch: https://core.trac.wordpress.org/attachment/ticket/23912/23912.6.patch, this could be used (with appropriate props ofc) for the suggested extensions.

And the handbook (​https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php-extensions) should be updated as well?

[jrf]

@dingo_d IMO, yes to both and the updated list of required and recommended extensions should also be used in #47454.

Maybe @rarst would also be so kind as to run his expert eye over this patch ?

[Rarst]

As of current patch, the list is way too wide. Many of PHP extensions used by WP core are optional, you can't rely on automated search to enumerate which of them are actually required. I did a manual pass years ago ​https://wordpress.stackexchange.com/a/42212/847

Also while technically being "extensions" some of these are de facto part of PHP core (e.g. date) and are redundant to require explicitly.

[dingo_d]

In your opinion @Rarst what would be the best way to handle the list? Remove the ones that come bundled with PHP, and the ones that are not required just push to suggested part of the composer.json?

[Rarst]

Since the scope of this composer.json is test environment really I would:

1. omit anything that is part of PHP core, that's just not necessary
2. limit require to the extensions that are hard requirement for tests to run/complete
3. limit suggest to the extensions that are optionally covered by tests (if any)