Drupal, Composer, Patches, & FreeBSD, Oh My!

Submitted by kentr on 02/20/2020, 19:41

Problem

Composer is now the recommended way to install / manage Drupal. That's all fine and good. Composer generally works well. But...

Incorporating patches into Drupal projects has become mainstream. So much so that cweagans/composer-patches is currently included in the standard Drupal composer template. Again, all fine and good. cweagans/composer-patches generally works well.

Until it doesn't... Like on FreeBSD and other OS's that don't support the --no-backup-if-mismatch option for the patch command.

Until that issue is resolved, FreeBSD users are out in the cold with cweagans/composer-patches. composer install fails if there are patches.

Solution

Here's what's working for me.

Remove composer-exit-on-patch-failure from composer.json

We'll remove cweagans/composer-patches from the main project, but it may be installed anyway as a dependency of one the project's requirements. In that case, cweagans/composer-patches will still run and fail.

To keep these failures from aborting the composer operation, make sure that this line isn't in the project's composer.json:

"composer-exit-on-patch-failure": true

Replace cweagans/composer-patches

Replace cweagans/composer-patches in the project with vaimo/composer-patches.

$ composer remove cweagans/composer-patches; composer require vaimo/composer-patches

In my experience, these changes should fix the installation problems on FreeBSD.

Comments

You might need to remote vendor/composer/installed.json after switching the package. both of the plugins rely on data kept in that file to determine if patch is applied or not and a complete reset to the packages is the best way to go (running "composer install" after the installed.json is gone will re-instal every dependency and assure that the patch plugin will start with clean slate).

Add new comment