Providing recommended dependencies locked to ones known to work in a Drupal distribution

Originally posted to:

The lock file in the composer create project situation but is mostly a red herring, as far as how Drupal keeps its dependencies in check. Telling people not to update their composer.lock file themselves but to just get updates to it from the project is far too brittle for Drupal (“don’t add any of your own modules, or your off of our tested update path”); if it works for our own purposes though we can use it ourselves and document that (#12) as the way we do it.

Anyway, what actually happens with Drupal’s “recommended” friends, since i spent way way too long figuring it out:

The version that is actually gotten when composer create-project drupal/recommended-project dirname is run is a tagged one with specific versions; these tags can be seen with composer show drupal/recommended-project --all and a chosen one can be added onto the create-project command to pick it.

The work of locking things down is not done in that composer.lock except insofar as it specifies a particular version of drupal/core-recommended (which likewise has a tagged version; see all available tags with composer show drupal/core-recommended --all.

The real work of making sure the next composer update doesn’t blast it all away into the latest and greatest symfony and all that jazz is done in drupal/core-recommended which is required by drupal/recommended-project, the lockdown (that sticks) is not in drupal/recommended-project itself.

Maddeningly the shown (HEAD) version of core-recommended is a nearly-empty composer.json file, making you think that metapackages are pure magic or something.

But look into a tagged version and you can see that all the dependencies are very locked down in (and only in) composer.json.

If we want to lock down Drutopia feature modules similarly when people run composer update, we would likewise have to create a composer.json with all of these tagged projects specified precisely, and update this for each release.

Drupal core has some automated way to do this for its (mostly symfony) dependencies, and that’s a trail i haven’t followed.

Drupal’s steps for creating a release are voluminous:

And don’t even mention some sub-tree split magic happening in the background.

As implied but maybe not clearly stated it’s the drupal/recommended-project’s composer.json that keeps your project on the straight and narrow through it’s requirement of drupal/core-recommended.

Asked in Drupal chat, composer room, for help:

How exactly is drupal/core-recommended and the subtree split and all that fun produced behind the scenes? Is there a documented process / tools that distributions of Drupal can / are encouraged to follow?

Other resources consulted: