Earlier this year I implemented the Composer dependency manager support in Yoast projects. In recent years I spent a lot of time to explore and promote the use of Composer in the WordPress ecosystem in general.
Implementing Composer in Yoast plugins is a great example of its success with WordPress projects, deployed on a widest possible scale.
Quick intro to Composer
Composer is a PHP dependency manager.
In simpler words it is a utility that helps developers to publish and consume code. It enables developers to define which code they need in their project. Then Composer makes sure it is all fetched and in line with version requirements.
The state before
Yoast projects already had and shared some internal dependencies. They were included via Git submodules, which tends to be a brittle approach.
Projects were shipped with configuration files for some tools, but not the tools themselves. An example of such tool is PHP Code Sniffer, which ensures that code adheres to mandatory coding style.
The autoload of PHP classes was custom coded. It had lists of class files which required ongoing maintenance.
Conversion to Composer
I started with a list of decision points for the implementation roadmap. After research and internal discussion we decided to:
- convert internal dependencies into Composer packages;
- switch autoload from custom code to Composer.
From there it was a clear path to make a branch and implement the necessary changes.
To easily adopt the new workflow I had documented instructions for all common tasks in the wiki.
PHP 5.2 compatibility
One big challenge was the demanding level of backwards compatibility. Composer requires PHP 5.3 environment and its autoload has the same target version.
PHP 5.3 was fine in development, but the plugins needed to ship for PHP 5.2 in the WordPress repository.
We had solved this with composer-php52 package. It allowed to keep the Composer workflow and build autoload files, compatible with PHP 5.2.
One of the big benefits of Composer is that it allows to have an extra development target for build. I used this to move development tools configuration into a Yoast Coding Standards package.
Now any Yoast project can require it to have access to the same baseline tools and rulesets. This simplified tools setup in Travis CI and development environments.
The next big item is to leverage Composer in premium Yoast plugins. Currently they're Git forks of their free versions.
We're planning to convert premium code into compact Composer packages. The free plugins will act as core packages and should work both with and without the premium code.
Composer implementation in Yoast projects:
- modernized dependencies;
- simplified autoload setup and code maintenance;
- made code quality tools and requirements more friendly to use and follow.
It serves as great use case of WordPress projects, powered by Composer.
Composer all the things! 🙂