Add a core lockfile creator to generate template lockfiles.

We might not actually want to do this. It gives the benefit of having a strict set of dependencies, but at the cost of making upgrades more difficult. Upgrading would require users to upgrade *both* drupal/core as well as drupal/core-strict, and if core *adds* a dependency that might cause issues as well.

Not having a strict set means that we risk having a state where we cant create the product if there is an upstream breakage in a dependency, which probably wouldnt be a big deal for the tarball, but might make composer create-project drupal/kickstart fail under certain conditions

So one thing that I was experimenting with is what happens when there is a composer.lock file that is included within the drupal/drupal-project-legacy repository when `composer create project` is executed:

Short answer is it works, except we cant just use the lockfile thats checked into drupal/drupal because it lacks the drupal/core and drupal/drupal-scaffold repositories.

I hacked together a composer.json that took the packages key from drupal/drupal's lock file, and merged it with the packages key from drupal/drupal-project-legacy after I ran a composer install, keeping only the drupal/core and drupal/drupal-scaffold keys, and lo and behold it installed the exact dependencies we want, without having the rigid requirement in the root composer.json - so if there's some way that we can generate these 'combined lock' files for the project templates, that would be ideal.

bonus points if that process can be reused by distro maintainers to also get a starting point of precise core dependencies.

We've identified a few mechanisms for how a drupal site should be managed with regards to the dependency management strategy we should adopt.

1. A core strict plugin that locks the dependencies to a specific version for each core dependency.

Pros:

• We can guarantee that the dependencies that the end user has have been tested, and they will not get a surprise upgrade

Cons:

• Upgrades are more complicated, because they have to upgrade core, and the core strict plugin at the same time.
• Having a very narrow set of acceptable dependencies can cause conflicts when adding newer modules with 3rd party dependencies.
• Possible that some dependencies have to be different between php7 , 7.1., 7.2, 7.3, and thus there is no "one true set of deps" that we can ship with.

This requires core to maintain the plugin in conjunction with the core lock file.
This Option is 'maximal safety'

2. A lock file that lives in conjunction with the template files

Pros:

• This would guarantee that when the tarball is constructed, or when the end user starts with a `composer create project drupal/{templatefile}`that they begin with a known, working set of dependencies, and do not start with any broken upstream surprises.
• No conflicts when adding modules,
• Upgrading is simpler (composer update drupal/core should be sufficient)

Cons:

• When users update core, or potentially add modules, their dependencies could update to the latest versions of dependencies

This would require that core maintains the lock files of any templates that it ships with. This one is 'Less safe, but flexible, and no risk of a broken product out of the box'

3. No restrictions, cowboy.

Pros:

• Most flexible, least amount of maintenance

Cons:

• Potential exists for an upstream bug to be introduced in a dependency, and an end users first attempt to use drupal is broken.

So, due to the nature of semver and dependency hell, there's really no way to simultaneously guarantee a set of dependencies that will work with drupal, and also guarantee flexibility in extending and upgrading.

In other words, this decision is really a 'what level of safety should we offer to our users?

Currently, we can see that there are a substantial number of sites out there that have selected option 3.

If we look at the download numbers for
https://packagist.org/packages/drupal-composer/drupal-project, it currently shows 230 695 installs, but that doesnt show the whole picture because there are many, many forks of that project.
A better place to look would be https://packagist.org/packages/drupal-composer/drupal-scaffold, because most of the forks still rely on that project. It has 2,488,381 downloads, whereas

https://packagist.org/packages/webflo/drupal-core-strict, the current implementation of option 1, only shows 154 980 downloads.

So, maybe option 3 isnt really all that risky? (or 2, for added comfort)

Also, we probably need this in conjunction, regardless:
#2874198: Create and run dependency regression tests for core

consider just adding drupal/core as a dependency to drupal/core-strict

Ah, yes, thats a much better option for the maximum safety option. ++

But I think we'd actually need two kickstart projects in this case, one that required drupal/core and one that required drupal/core-strict.

And our ability to have multiple kickstarts that ship with core is a feature of this architecture.

we should confirm that this works as designed if we haven't already.

Im pretty sure thats the intended behavior, as thats the only way to interact with a lock file directly from composer without already having git clone of a project, but I can reconfirm that.

Okay, I've got an experiment up and running at https://github.com/drupal/drupal-project-legacy which includes a .lock file.

Im very confident in this going forward, so Im going to go ahead and repurpose this issue to be where we add a script to core such that when core commits a new lock file to the repo, it subsequently updates the lock files in any of the template projects such that templates moving forward begin with the correct dependencies.

This script *may* be of use to distribution maintainers as well, under the assumption that they too may wish to have a similar lock file shipped with their starting point templates.

I do not see this script as being a blocker moving forward, more like a convenience to make it easier or core maintenance to ensure that the template locks are kept in sync with core's .lock file changes.

Update on this issue:

We'll continue to have a lockfile in the root of the repository, and we'll use that to create a metapackage for 'core-pinned-dependencies'.

This metapackage will have cores dependencies pinned to specific versions, and will require drupal/core itself.

This will allow consumers of this package to avoid having to update both drupal/core and drupal/core-pinned-dependencies at the same time.

The metapackage creation should be a process that runs on drupal.org's infra and extracts the info from the lockfile.

drupal/core-recommended-dependencies

is the name we're settling on.

Opened https://www.drupal.org/project/infrastructure/issues/3076600 for the infra side of this.

I probably should have just moved this over to drupal infrastructure, but theres really nothing to commit to core for this issue. closing in favor of the other issue now.