Composer roadmap

[Rarst]

Hi! I am your resident Composer menace.

I am working to make WP SEO have awesome Composer support. Because Composer is what keeps developers happy and managing dependencies reliable (audience cheers).

As well as hopefully simplifying development and build processes away from Git Submodules (audience moans).

The current state

1. Present composer.json in main plugin, but broken due to submodule use
2. Two submodules without Composer support

Decision points

Is it time for submodules to go?

Should the submodules be retained in parallel? Or should Composer become main and preferable mechanism with submodule structure deprecated?

How will we handle autoload?

The tricky part is to enable end result to work seamlessly with PHP 5.2 (audience moans).

While you can use Composer to build for PHP 5.2 target without issue, its autoload is inherently 5.3.

From my research so far I see two approaches:

1. Ignore Composer autoload, rely on known dependency locations in tree to load files. Vendor directory can be discarded in build process. As part of the site stack the built in load should be ignored in favor of global Composer autoload.
2. Use the intermediary classmap, generated by Composer. While that "magic" autoload in Composer requires 5.3, it also generates intermediary files which seem not too. One of those can provide classmap, mapping classes to their filesystem locations. This file can be used in internal autoloader, over hardcoding the locations.
3. composer-php52 was brought to my attention as an option for autoload compatibility layer, h/t @coenjacobs

There might be more options to explore here as well.

Progress

• implement Composer in libraries used
• add libraries to Packagist
• require libraries in plugin
• fix Composer installation to work
• document
• update build process (see Update deploy implementation #1961 )

Relevant pull requests

• Composer implementation for dependencies and autoload #1912
• https://github.com/Yoast/License-Manager/pull/57
• Composer support i18n-module#2
• Raised composer-php52 version #1958

[jrfnl]

@Rarst While from a developer's point of view, your intentions are understandable and good practice, let's not forget the reality.

The reality is that this is a WP plugin. My estimate is that 99% of WP users have never even heard of composer and that 99.9% have never used it.
After all, the average WP user is not a developer.

The most common way to install WP plugins is via the standard WP plugin install mechanism. The way the plugin is now set up with submodules, autoload working the way it does etc works in 100% of the cases for the normal WP plugin installs.

Do we really want to spend effort on something which might be used by 0.1% of the users - if at all ?

I'd suggest your time and effort is better placed in trying to get WP to up the mimimum requirement to PHP5.4 (or even better: 5.5) and to open up the discussion there of replacing the plugin install mechanism with a composer based system.

Anyways, that's my two pennies...

[coenjacobs]

@jrfnl I think you misunderstand the purpose of Composer autoloading and how this gets deployed to the wordpress.org plugin repository. Composer autoloading generates files that can be included to add autoloading to your project. Developers of this project just need to include the Composer generated autoloading files to the package that can be downloaded (or updated) via the plugin repository. The end user doesn't even need to know Composer is there, let alone be able to use it.

[Rarst]

The most common way to install WP plugins is via the standard WP plugin install mechanism.

This will not in any way compromise the regular distribution and install channel. It wasn't even remotely considered. :) This is development experience improvement, nothing changes or get sacrificed for the users.

I wouldn't push for any change that would come with regression. The point is to improve.

I'd suggest your time and effort is better placed

My time and effort are perfectly placed here, since this is paid work for Yoast. :)

[jrfnl]

@Rarst Point taken.

@coenjacobs I probably do. So far my experiences with Composer have been limited as I quit trying after abysmal experiences with it on Windows. I have taken note of the notion that Windows support has improved over the last six months, but am very wary and sceptical after having been bitten before. That taken together with the x times duplicate code being littered all over the place, which still doesn't make any sense to me and the amount of config it takes to avoid that, gives me very little motivation to spend any time on giving it another try.

[Rarst]

I quit trying after abysmal experiences with it on Windows. I have taken note of the notion that Windows support has improved over the last six months

Interesting point, since I am pretty much exclusively Windows user locally and hadn't had major issues in about two years of using it.

I will do my best on smooth and well documented experience here. :) You are welcome to contact me if you need any pointers in this context or about Composer in general.

[jrfnl]

@Rarst I appreciate the offer and might take you up on it when I have some time to have another look at it. Thanks.

[Rarst]

Looked into how composer-php52 works. Essentially it implements my idea from (2), making use of classmap already generated by Composer and wrapping it into 5.2–compatible loader implementation. Looks solid. Hadn't tested out in real 5.2 environment yet.

[Rarst]

Stalled on decision about retaining submodules to start on an implementing branch. In my opinion they should go, but that's from where I stand. cc @jdevalk

[jdevalk]

Let's ditch 'em, but the team will need a proper explanation on how to do a new checkout :-)

[Rarst]

Of course. :) Once I have working branch, I'll write up the documentation and work with everyone who needs it on the new process.

[jdevalk]

👍

[Rarst]

First draft of documentation is up: Using Composer

[jrfnl]

@Rarst I had a quick look a the documentation. Just checking if I understand correctly: does this mean that each time you do a git checkout or switch branch, you need to run a command line command as well to verify the dependencies are still correct ?

[coenjacobs]

@jrfnl That's correct. composer install ensures you have the dependencies installed according to the composer.lock file (or composer.json if there is no .lock file). This file can change between commits and branches, so yeah you need to run the command at least after checkout and switching branches.