[Flow] Commit the composer.lock file or not?

[Jacob Floyd]

Long term, I think we could solve this like so:

On update, store the composer.lock file separate from the git repository.
That
would probably mean that we'd put composer.lock in .gitignore, and require
some
kind of server-side git hook like update (which is triggered per branch).
When
the hook is triggered, an automated task (perhaps on Jenkins, but not
necessarily) would trigger an update similar to the git submodule pointer
updates we know and, um, hate. Only, instead of committing the updated
composer.lock files to the git repositories, it would send the updated
composer.lock to a specialized web service.

Awhile ago, Sebastian Kurfürst and Thomas Maroschik wrote a proposal on how
to
build the next generation Flow server[1]. Though some of the details may
have
changed since it was written, the concepts are still valid. Essentially, we
will
be hosting something like packagist that does a lot more than packagist
does.
We can store the composer.lock files in the artifact repository, and then
hook
into the composer process (somehow) to inject our prepared composer.lock
files.
Different agencies could probably host their own artifact repository to
store
their lock files, but I think the idea of storing the composer.lock file
somewhere
other than in the git repo is feasible.

Et Voilá! We have the benefits of the composer.lock file without the
deficits
of committing to the repo.

Since we will have control over the Neos UI for an extension-manager-like
package manager (along with the backend components), it will probably be
easiest
to implement this for Neos, and then figure out how others can take
advantage of it.

This doesn't help us today, but hey, I think it's a good direction.

[1]
https://docs.google.com/document/d/1uFyP1H559OFAcqUKiz3uEBdpdqqs4B22AbpnaoNsfvY/edit

Cheers,
Jacob Floyd