Remove Composer lock file

[allejo]

Do we actually need a lock file for a library? There's nothing for us to deploy so we don't need to lock in any of the dependencies. Our only dependencies are dev dependencies, which I don't think we need to lock.

[jaapio]

I think there are a few reasons to keep the lock file.

• Speed, composer install is way faster when using the lockfile. Since it only has to download the dependencies
• consistency between builds, the lockfile prevents unexpected upgrades of our dev dependencies.

In this case the defined versions are quite strict so it shouldn't be a problem at this moment. But I think we might want to reintroduce it at some point. I'm missing some reasoning in your pr why you want to remove it. Just removing the lockfile without any arguments is not very plausible for me.

[allejo]

consistency between builds, the lockfile prevents unexpected upgrades of our dev dependencies.

I've got no argument against this, I agree that it'd let us replicate dev builds accurately if we need to track down some issue with our dev tools.

I think that not having a lock file, while slower, would let us actually find issues with our dev tools quicker. Since we'll always be using the latest version (per our composer.json requirements), we'd notice something amiss sooner rather than later when we update our dependencies. Removing the lock file would also allow us to remove the need for PRs like #194 and whichever new PR comes along that will update the phpstan dependency, which currently breaks with our 7.4snapshot testing. The lack of 7.4 compatability has already been fixed upstream (phpstan/phpstan#2275) and will be available in 0.11.13 or whichever the next release is.

My thinking is that as long as our composer.json requirements are strict enough to prevent pulling down major breaking changes, we'd get the benefit of not having to worry about explicitly updating our dev dependencies and just triggering new builds instead.

[jaapio]

I have my doubts about this pr. But I would agree with a second opinion form another team member to have this merged.

I requested a review from the team. Let's see what others are thinking about this :-)

[localheinz]

Personally, I would suggest to keep composer.lock

Also see http://naderman.de/slippy/slides/2018-01-26-composer-lock-demystified.pdf.

[mikey179]

I always keep the composer.lock file in my projects, regardless of whether it's a library only or not. Reproducibility is a big asset I wouldn't throw away lightheartedly. I think it's also helpful for contributors - when tests work on their machine but not on Travis different versions of dev dependencies can be ruled out. It's great they want to contribute - don't burden them with figuring out problems due to different versions.

[jaapio]

We could start using dependabot. That will help use to keep up to date?

[allejo]

I'm not adamant about removing the lock file, I'm totally fine with keeping it for speed and reproducibility of builds, so I'll close this PR.

+1 from me for giving dependabot a try if others are interested as well.