Updating Composer to Account for Dev Modules

Alex Manzo on background

Alex Manzo —

Scroll Trigger Image

In some recent updates to our site, we added a Drupal module still in development. All of our local testing worked without issue, but after deploying to Pantheon, we were unable to configure the module because, according to Drupal:

Unable to install the module since it does not exist.

I've run into this error plenty in local development, but had never run across it after deployment. For some quick context, our process look like this at a high level:

  1. Install dependencies locally and commit composer.json and composer.lock. We do not commit dependencies to the repo on this project.
  2. When we merge into our master branch, a build on Travis CI is automatically triggered. In addition to testing, this build runs composer install, builds our theme, and automatically deploys to Pantheon.

After some quick checks locally, I decided to pull the code directly from Pantheon to see what was going on. I found that while a directory for the module was created in modules/contrib, it was empty.

We've run into a similar issue in the past on projects where we did commit dependencies. In those cases, we were able to solve the problem by verifying we aren't committing git submodules. While we aren't committing them locally, we surmised they still might be committed after the Travis build ran and deployed to Pantheon. To get around this, we set up a remove-git-submodules script to run both post install and post update:

find . -mindepth 2 -type d -name '.git' -not -path './web/sites/*/.git' | xargs rm -rf

That on its own still wasn't enough to address the problem, unfortunately. I started digging in a little further and took a closer look at the make command we use for composer install, and remembered we always include the --prefer-dist flag. Then it clicked: this module wasn't installing simply because there was no dist directory to build from. I removed the flag from our make command and updated composer.json to use --prefer-source for this particular module, but still ensure we run --prefer-dist for the rest.

"preferred-install": {
  "drupal/linkchecker": "source",
  "*": "dist"

This update (along with uninstalling the module, deploying, and then re-installing and deploying) is what got us to where we needed to be. These are two simple additions to your composer.json that can potentially save some trouble down the road!