As discussed in a previous blogpost, how do we help ease the (hopefully) inevitable transition of Drupal towards Composer? Well, a major barrier to adoption is that many people who use Drupal have a vested interest in makefiles: rewriting the actual files themselves would involve paying back a lot of technical debt.
There are two ways to guide people through a transition which might require paying back technical debt:
- Make the alternative of doing nothing so expensive that people invest and move on
- Reduce the overall difficulty by providing temporary "transition technology" early on, to make repaying the technical debt sooner more attractive
The former will happen sooner or later: you just don't know when; and it will be no fun at all to be involved in any project that gets caught up in that chain of events. Far better to promote the latter, if at all possible. With that in mind, here's a Drush command that automatically converts Drush makefiles to composer.json files. It's so beta it will blow your wig off and possibly your leg, so please be careful with it.
There are still a number of limitations of a direct conversion, which are difficult to tackle automatically. These include:
- Patches: for better or worse, Drupal is wedded to a patch-based workflow. Indeed, there's several arguments that suggest they're an improvement on pull requests. But that does mean patch URLs are dotted through makefiles like a rash, and unfortunately Composer doesn't understand them at all. Or does it? Hey, what's that over there? That's right, it's another beta project to support post-install patching in composer (edit: on Packagist, too!) Gaze in awe, or shrink in horror: the choice is yours.
- Folder structure: the standard way to support installing outside of composer's vendor/ directory is to use composer/installers. But their default installer assumes you're only building sites/all, and provides folders accordingly (modules in modules/ etc.) That means core ends up in, well, vendor/drupal/drupal (!) There are other solutions but they're self-described "opinionated": which means they're arguably not suited to be transition technologies, where your project's itch needs to be scratchable during transition, or it won't make it through the technical debt. In theory, Drush instance could be straightforwardly extended to script a lot of this, and maybe now this issue in the queue is more relevant than ever, although there will still be the issue of updates to tackle, especially difficult in a rearranged codebase....
- Zipfile repositories and updates: having hardwired repositories in composer.json isn't ideal (indeed, it's what makes the composer.json files so long-winded in the first place.) However, as discussed there are no official d.o packagist-like repositories out there, and the unofficial ones are again decidedly opinionated. Another main issue of zipfile-based repositories is that they seem to make Composer very poor at detecting e.g. updates to composer.json: I've received a "no updates" when a version number has clearly been changed in the past. There's no amazing solution to this that I can see, but I'd appreciate suggestions.
Anyway, Drush Make To Converter. Composer Post-Install Patch Applicator. Go crazy. Repay your technical debt, if you can. Just don't blame me if interest rates on it can rise as well as fall.
