Update composer for lightning

[damontgomery]

The solves this use case,

As a developer, given I have installed bolt with lightning, I get the most up to date version of lightning.

Currently Bolt installs old versions of lots of it's dependencies. I would argue that the composer.lock file is relevant to projects with set functionality.

https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file
Commit your application's composer.lock (along with composer.json) into version control.

A template is not set functionality, it is intended to be immediately updated my adding modules and removing them.

It is unreasonable for Bolt to constantly track all of the dependencies and make PRs for every small change.

More importantly, it is unreasonable for users to receive an out of date project and be expected to determine which pieces, like lightning, are immediately out of date.

If you want to lock down composer dependencies, you might as well ship with docroot already built as well. What happens if the dependencies disappear overnight? Bolt stops working all the same.

The risk here is that dependencies stop working.

To address that, you can lock down all of the dev dependencies with specific versions. Or, you can run daily builds on the project and get notified when conflicts arise. Those are real solutions to the problem.

[geerlingguy]

Should we stick with ^8.0 for now? I think 9.0 is basically the current 'experimental' branch undergoing a full rearchitecture.

[damontgomery]

Lightning requires 9.0 for now, so you'll get it anyway.

[damontgomery]

To be clear, projects should use composer.lock and they will get their own one when they create a site with bolt. From that point forward, it is up to them to maintain that file.

[CashWilliams]

I like this for 2 reasons -

• Anything 'upstream' shouldn't provide a lock file. This includes the bolt template, lightning, and even Drupal core (the latter 2 we'll have to fix somewhere else).
• Also this gets us on a real version of Drush instead of master, which I think composer can then cache the tar file, so local re-installs will be faster.

[damontgomery]

I think the key quote from the docs is this, However, this lock file will not have any effect on other projects that depend on it. It only has an effect on the main project. https://getcomposer.org/doc/02-libraries.md#lock-file

If you want to lock down a dependency, set it at a specific version. I think this should only be done (if ever) for bolt on development dependencies. These are not included in the artifact, so it's reasonable that you'd want all the tools to be consistent. This does not apply to all the parts of the project that will make it into the project artifact.

[CashWilliams]

I'd click the merge button if I had merge privileges.

[grasmash]

After reading a good deal of backscroll in the Bolt chat room, I'm willing to support this approach.