Drop composer.lock from the committed files list

[Slamdunk]

As discussed in #1105 (comment) , the drop of the config.platform entry from the composer.json needs the composer.lock to be dropped as well to avoid invalid lock file updates from renovatebot.

Since we already test against both lowest and highest and the locked are the lowest anyway thanks to renovatebot itself, this should be fine.

[Ocramius]

IMO this patch is a problem for reproducible builds, and for identifying regressions in dependency changes: lowest/latest are spearheads, while locked is a stable/verified build that should be preserved, from a design PoV.

[Slamdunk]

Facts are:

1. config.platform blocks us from testing against deps that require different PHP versions
2. renovatebot doesn't play well with config.platform specified but composer.lock uncommitted

My opinion is: yes we lose reproducible builds, so what? The scenarios are:

1. build goes red on locked but green on highest: composer.lock is useless
2. build goes green on locked but red on highest: we already catch this with renovatebot

Am I missing something?

[Ocramius]

It aids you as a maintainer right now (frustration of current moment), but it hinders others hopping in and contributing, including @renovatebot.

From my PoV, reproducible builds are way more important than being able to try latest/greatest: you leave packages sit around for half a year (because life happens) and you can go back to them and collaborate, while non-reproducible builds are always an unhappy adventure.

[lcobucci]

I fully agree with @Ocramius here. Lock files are important not only for CI but also for the library's development.

It's way more frustrating to have things randomly failing locally due to unexpected dependency updates.
Please, let's not proceed with this.

[Slamdunk]

Then please approve #1094 so I don't have to spend 10 minutes every time figuring out what binaries I need on my computer to have a green make run