Don't remove composer.lock in test runs

[beberlei]

Bug Report

Q	A
BC Break	no
Version	2.10.0

Summary

.travis.yml removes the composer.lock and then makes an composer install (being an composer update). This pulls in new dependencies in stable branches that weren't tested against causing errors (PHPunit + stopOnWarning=true).

[beberlei]

Fixed in #3778

[greg0ire]

This pulls in new dependencies in stable branches that weren't tested against causing errors (PHPunit + stopOnWarning=true).

And that's good, isn't it? You want to know if things go bad because of a dependency, especially if the dependency itself is a Doctrine package. If it's not, you want to protect your users from the error by either reporting the bug, or fixing the issue if it's caused by a misuse of the API of the dependency that wasn't checked for before and is now.

[morozov]

It's not true for development dependencies. We don't want the build to fail and require immediate reaction just because a new version of PHP_CodeSniffer or PHPStan detected some new issues in the code. It is true for the production dependencies but in this case, we may have a special build job that does composer update and is allowed to fail.

[greg0ire]

IMO phpcs and PHPStan shouldn't even be part of dev dependencies, but if this is really an issue, there is a simple solution that consists in pinning those to a version number and update them when we really want to.

[morozov]

IMO phpcs and PHPStan shouldn't even be part of dev dependencies […]

This is an entirely different conversation. While I agree in general, there doesn't seem to be an existing alternative to automate the installation and version control of development dependencies. How would you install the required version of PHP_CodeSniffer with the needed version of Doctrine Coding Standard, Slevomat Coding Standard and their dependencies?

Apart from that, in the setup I'm using for the last few years, I have vendor/bin as part of my $PATH, so I can use all the dev tools of a given project just by invoking them like phpunit. Not using Composer would require solving this problem as well.

[greg0ire]

This is an entirely different conversation.

Yeah and I'm sorry because you probably have had that conversation already :sweat_smile: it's all connected…

How would you install the required version of PHP_CodeSniffer with the needed version of Doctrine Coding Standard, Slevomat Coding Standard and their dependencies?

I'd use phars for most things, but for that, I have no solution apart from maybe https://packagist.org/packages/bamarni/composer-bin-plugin .

I have vendor/bin as part of my $PATH

Neat! I'll probably do the same! I think the package above would also solve that issue (it puts the binaries in the same location you are using right now)

[morozov]

Since we're in a rapidly changing open-source environment, using PHARs as a package maintainer may be not always convenient. There have been a lot of times when bumping a development requirement dependency causes false-positive failures that sometimes require debugging and modification of the source code of the dependencies.

I look forward (I mean it) to seeing an alternative development dependency management solution that would be as usable as the current one and not cause the undesired side effects.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.