Drupal-project: Commit composer.lock to repo

[ashabed]

The initial create-project command takes ages and fails for slower computers/connections. I see this frequently in the classes I teach ( DebugAcademy.com). Every semester, day 1 includes half the room's composer create-project command failing.

Are you open to committing composer.lock to this repo to enable people with slower machines & connections to use the template?

[greg-1-anderson]

I am 👍 on always having a lockfile. In the typical case, a new user who runs composer create-project will get exactly the dependencies last tested with, which will lead to a more stable experience. Those who don't care about the lockfile can easily run composer update to get rid of it.

[leymannx]

I'd rather vote against a lock file in the repo. It needs to be maintained.

Debug Academy could simply create their own fork of this template where they commit a lock file to.

[greg-1-anderson]

There was some discussion of this on slack. One of the main arguments against the lock file is that composer update runs against one particular set of platform requirements. If the committed lock file was built for PHP 7.3, then it would certainly contain dependency versions that did not work with PHP 5.6. If it was built with PHP 5.6, it would likely also work with later PHP versions, but this could not be easily proved, and the lock file certainly would not contain the best dependency versions for PHP 7.3. The wider the spread between supported PHP versions, the more of a problem this is likely to be.

Since this is a community-supported project, not Drupal Core, I tend to think that we could support a very narrow band of PHP versions, and include a lock file. Maybe the better solution, though, would be to simply try to make Composer faster.

[amaisano]

Isn't there a line in composer.json that provides a PHP version context? That would make clear what platform our dependencies are being gathered for, wouldn't it?

...
 "require": {
        "php": "~7.0",
...

[greg-1-anderson]

Yes, currently this project uses "php": ">=5.6",. This allows for multiple versions of PHP, though. The exact dependencies you get will vary depending on what version of PHP you use to run composer update on. The PHP version can be more strongly constrained by setting the platform php in the composer.json extra section, but this does not really get around the problem I describe above, that you have to pick one particular php version to generate the composer.lock file for.

[ergophobe]

I came across this long for something else and noticed this discussion and thought I would chime in with a recent issue I had.

On my dev platform, the webserver was running PHP7.3 and the CLI was still on PHP7.0. When I did a composer update (so on PHP7.0) that crashed the site - white screen of death. I changed the CLI to PHP7.3 and did another update and everything was fine.

Why? Because though Drupal was the same for both, Symfony is not. You might think that PHP7.0 packages of Symfony would be fine on a PHP 7.3 server, but for whatever reason they were not. And I figured that out because I found other people reporting the same thing, and not just for Drupal, so it's not some strange thing with my environment.

I think it highlights how thorny this problem is. All you need is one package that is different when making a minor version change to PHP and everything comes crashing down.

I would not wish that headache on the maintainers.

[leymannx]

Won't fix.