drupal-core-require-dev vs. drupal-core-strict

[ultimike]

I've asked this on a couple of different social media sites without much response, so I figured I'd come straight to the source...

When using the drupal-composer/drupal-project Composer template for #drupal 8 projects, I’ve always wondered a bit about the webflo/drupal-core-require-dev dependency. I think I understand it, but looking for confirmation.

It is described as a virtual package, designed only to specify version constraints for #drupal core dependencies. Its webflo/drupal-core-strict sibling specifies the exact version of Drupal core dependencies to use - not a range like drupal-core-require-dev.

drupal-core-strict specifies the exact dependency versions listed in the composer.lock file in the corresponding Drupal core release.

drupal-core-require-dev specifies a range, so if a dependency has been updated after a Drupal core release, you could end up with a different version (which can cause issues) Do I have this all correct?

If I have this all correct, it would seem to me that using drupal-core-strict would be a better way to go for most projects.

Finally, what is the best process for modifying an existing project to switch from require-dev to strict?

[greg-1-anderson]

Partial answer: https://github.com/drupal-composer/drupal-project/issues/477

Don't have time to type more now but will circle back later. Ping me if I forget.

[ryanaslett]

also, 'can cause issues' should never cause issues with a live site, only potentially with your development workflow and testing procedures.

[greg-1-anderson]

One thing that I find a little odd about drupal-core-require-dev and drupal-core-strict is that the former constrains the version of drupal/core that it will work with, whereas the later does not. I would tend to think that drupal-core-strict had as great a need to be tied to a specific version of drupal/core. Of course, if you have your dependencies wrong, then the Drupal unit tests might not (probably will not) pass, so if you are using drupal-core-require-dev to run the Drupal tests, constraining the version of drupal/core is also important there.

Most people don't run the Drupal tests, though, and just use drupal-core-require-dev to get the dependencies they need to run their own tests. Given the problems with updating that are introduced with these projects, I think that most people are better off copying the require-dev dependencies they need into their top-level composer.json file, and only use drupal-core-require-dev if running Drupal's tests.

Modifying an existing project to switch from require-dev (or nothing) to strict can be problematic, especially if there are newer dependencies in your lock file than in drupal-core-strict (as one would expect there should be). In theory, the Composer solver should be able to try all permutations and come up with the right dependencies, even when making a complex change like this. That's why everyone is so enamored with the solver, right? In practice, though, Composer usually gets confused and cannot add in drupal-core-strict or drupal-core-require-dev if there is an existing lock file. The solution is to modify your composer.json file, attach the same version limit to drupal/core and drupal-core-strict (e.g. ^8.7.3) to limit what the solver needs to look at, and then remove both your composer.lock and your vendor directory and run composer updateorcomposer install` (which both do the same thing in the absence of a lock file).

In the balance, I think that the problems caused by the Composer solver are greater than the benefits that it provides. I believe that the solution to these problems would be to rewrite composer update to not use a solver. This would introduce new, different problems, but I think they would be easier to deal with. I discuss this in the g1a/reposer README. I've been wanting to write a prototype for this, but I haven't had time because I have been working on the Composer in Core Initiative.

[ultimike]

Thanks @greg-1-anderson for the in-depth answer.

1. I'm wondering if the lack of drupal/core in drupal-core-strict is just an oversight.
2. For switching from drupal-core-require-dev to drupal-core-strict for existing projects, one issue with you solution is that if the site has numerous contrib modules that are not up-to-date, then using your process it will update all the modules at once - usually a less-than-ideal situation. But, I'm hard-pressed to find an easy way to do it...
3. Rewrite composer update? I'll just back away slowly from that one :)

thanks! -mike

[greg-1-anderson]

For 2, I would recommend getting all of your contrib modules up to date before adopting drupal-core-strict. Having your modules up-to-date is of more practical importance than using drupal-core-strict. If for some reason you cannot update some contrib modules, and you still want to use drupal-core-strict, I would recommend:

1. Pin your contrib modules that are not updated to an exact version in composer.json.
2. Remove vendor and composer.lock, add drupal-core-strict, and generate a new lock file.
3. Remove the pins of your contrib modules in your composer.json by adding ^
4. Run composer update --lock

Your project should at that point be back in a good state, with some contrib modules not yet updated to the latest version, but ready to be updated when desired.