Remove composer.lock

[pamil]

Q	A
Branch?	1.0
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets	-
License	MIT

Pros:

• always testing against the latest versions of dependencies (so that you can do composer update without fear when having sylius/sylius as a dependency)
• no weird problems with testing different Symfony versions (one of the scenarios: composer.lock comes with sylius-labs/associations-hydrator:v1.1.0 which supports symfony/symfony:^3.4, then it crashes when trying to require symfony/symfony:3.3.* for testing purposes)
• less conflicts when merging branches 1.0 -> 1.1 -> master or rebasing PRs

Cons:

• always testing against the latest versions of dependencies (so that your PR can fail because of a regression in a dependency)
• takes more time for Travis

[mbabker]

always testing against the latest versions of dependencies (so that your PR can fail because of a regression in a dependency)

Try adding a build passing the --prefer-lowest flag to composer update. In some projects I have a build on the lowest supported PHP version with that flag and that'll force Composer to resolve dependencies matching the minimum defined in your composer.json file (and those of your dependencies). Theoretically you should then be safely testing against your project's minimums and the latest versions of everything (this is also a good way to find out if your minimum declarations are actually valid).

[pamil]

@mbabker if --prefer-lowest would apply only for the root requirements, then it would be an awesome solution. Right now it's not really usable, as every dependency (or a dependency of a dependency) with wrong constraints would make our test suite fail.

[mbabker]

It's a hit-or-miss thing with that. On the one hand, it is resolving the lowest dependencies for everything (both root and transient dependencies) so it really is an accurate representation of "everything works on the lowest declared minimums". On the other hand, that flag makes things a lot more dependent on the full dependency tree being declared correctly, so if a transient dependency has a minimum that causes issues then it does fail your whole build (I've run into that one a lot on packages that have minimum dependencies to releases before PHP 7 support was added and those builds fail because transient minimums allow the earlier non-PHP 7 compatible releases to be installed still).

[pamil]

Yeah, with ~170 dependencies it's quite rare that all of them defines right dependencies requirements, but it's definitely an idea for the future to reconsider.