WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 weeks ago

#47256 new enhancement

Use composer to install and update external PHP libraries

Reported by: spacedmonkey Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.2
Component: Build/Test Tools Keywords: has-patch needs-testing
Focuses: Cc:
PR Number:

Description

As of WordPress 5.2, the minimum version of PHP requires was changed to 5.6. This opens up some options around how PHP dependencies can be managed. Composer is a popular PHP dependency manager similar to npm or yarn for javascript. WordPress core has support already got support for composer since 4.7. Since 5.0, many of the javascript dependancies are now loaded in using npm, php should have a similar build step.

Here are a list of dependancies that could be loaded in using composer.

If there are modification to these library in core, these libraries should be forked and maintained outside of core. Composer has a custom install path feature, that may allow us to maintain the current file structure. However, it may mean creating a new vendor directory (wp_vendor) and use autoloading.

Loading composer these via composer will remove a lot of the bloat of the code case, will make it easier for the core to manage updates in the future.

Attachments (2)

47256.diff (1.4 KB) - added by spacedmonkey 5 months ago.
47256.1.diff (2.7 KB) - added by pierlo 5 weeks ago.

Download all attachments as: .zip

Change History (12)

@spacedmonkey
5 months ago

#1 @spacedmonkey
5 months ago

As a talking point, I create the first patch 47256.diff. The patch is completely untested. But it does maintain the directory / file location using a package called mnsami/composer-custom-directory-installer.

This ticket was mentioned in Slack in #core-php by spacedmonkey. View the logs.


5 months ago

#3 @swissspidy
5 months ago

As of WordPress 5.2, the minimum version of PHP requires was changed to 5.6. This opens up some options around how PHP dependencies can be managed.

Since this is only meant for during the build process, the recent PHP version bump should be irrelevant for that, no?

If we want to have autoloading as well, I'd suggest continuing work on #36335.

If there are modification to these library in core, these libraries should be forked and maintained outside of core.

If only minor modifications are needed, the most common approach is to use patches.

But it does maintain the directory / file location using a package called mnsami/composer-custom-directory-installer

Hmm that package seems to be quite popular, but not very actively maintained. Might this become an issue?

#4 @johnbillion
5 months ago

  • Focuses coding-standards removed
  • Keywords has-patch needs-testing added; needs-patch removed

There's also oomphinc/composer-installers-extender which is much more popular, even if it too hasn't been updated recently. We use this at Human Made for client projects.

#5 @giuseppe.mazzapica
5 months ago

Would not make sense to write a custom installer?

The installer code would be quite simple, according to the current patch, it could be something around the lines of (completely untested):

<?php
use Composer\Config;
use Composer\Installer\LibraryInstaller;
use Composer\Package\PackageInterface;

class WordPressLibInstaller extends LibraryInstaller
{
    const SRC_BASE = 'src/wp-includes/';

    const PACKAGES = [
        'paragonie/sodium_compat' => 'sodium_compat',
        'paragonie/random_compat' => 'random_compat',
        'pomo/pomo' => 'pomo',
        'simplepie/simplepie' => 'SimplePie',
        'rmccue/requests' => 'Requests',
        'pear/text_diff' => 'Text',
        'james-heinrich/getid3' => 'ID3',
    ];

    private $vendor;

    public function getInstallPath(PackageInterface $package)
    {
        $name = $package->getPrettyName();
        if (empty(self::PACKAGES[$name])) {
            return $this->defaultVendor();
        }

        return self::SRC_BASE . self::PACKAGES[$name] . '/';
    }

    public function supports($packageType)
    {
        return $packageType === 'library';
    }

    public function defaultVendor()
    {
        if (!$this->vendor) {
            $this->vendor = $this->composer->getConfig()
                ->get('vendor-dir', Config::RELATIVE_PATHS) ?: 'vendor';
        }

        return $this->vendor;
    }
}

Which has basically the same maintenance burden of the config in the installer-paths array in composer.json.

Last edited 5 months ago by giuseppe.mazzapica (previous) (diff)

#6 @netweb
5 months ago

  • Component changed from External Libraries to Build/Test Tools

Switching the the component to Build/Test Tools which is where other tickets discussing Composer reside.

This ticket was mentioned in Slack in #core-js by omarreiss. View the logs.


3 months ago

#8 @pierlo
5 weeks ago

Copying the library using a custom installer would also include additional files bundled with the library that is not relevant to the project. Adding the libraries to composer.json then using a script to copy the needed files (such as the Webpack copy plugin) would be the best option for now until autoloading is possible.

@pierlo
5 weeks ago

#9 @pierlo
5 weeks ago

47256.1.diff shows an example of getting the dependencies through Composer then using the Webpack copy plugin to update the libraries in src/wp-includes.

This ticket was mentioned in Slack in #core-js by pierlo. View the logs.


5 weeks ago

Note: See TracTickets for help on using tickets.