-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not depend on phpspec/prophecy #5033
Comments
This has been discussed in #4141 and #4142. TL;DR: The dependency on Prophecy has been removed for PHPUnit 10. Anything related to out-of-the-box support for Prophecy is deprecated since PHPUnit 9.1. If we remove the dependency on For developers who use Of course, we should be able to detect in However, I do not know what to do here. If we do not do anything, PHPUnit 8.5 and PHPUnit 9.5 cannot be installed without hassle until Prophecy allows PHP 8.2 in their |
thanks for the in-detail anwser. great to see this is a solved problem for phpunit 10+. after reading your reply I get the feeling the easierst way forward, without BC breaks etc, would be to make people aware of the workaround, namely using the |
According to phpspec/prophecy#556 (comment), the following also works:
|
Also note that you do not suffer from this problem if you use PHPUnit from a PHP Archive (PHAR) instead of installing it using Composer. |
Never used
|
…ment) as well as possible workarounds
I have added a section on this to the documentation for PHPUnit 8.5 and PHPUnit 9.5. |
This would be the patch for the If we released a PHPUnit 9.5.23, for instance, with these changes then
Developers that use This would not result in an API BC break, but it would make a Thoughts? PS: If we do this, then these documentation changes need to be reverted: |
I would be fine with this approach (dropping the dependency). |
To clarify, I would not recommend to replace dependencies in packages: when a package A requires a package B, and package B replaces package C, then package C will not be available for package A, and of course, neither for dependents of package A. It's totally fine to replace packages in applications, though! |
Same dropping the dependencies is fine by me even if means I need to declare it explicitly (in my composer.json) to use Prophecy. @sebastianbergmann as always thanks for for your work. |
Throwing an error saying something like As said above by other peers, it would have zero impact on devs that don't use prophecy (like me), and will be part of the natural upgrade process for devs using it and migrating to newer versions of phpunit |
Do you think that
good enough as an error message? |
As a user that's still using prophecy for mocks, I would say it's fine to remove the dependency from PHPUnit.
|
Thank you all for your valuable input. These changes will be implemented for PHPUnit 8.5.29 and PHPUnit 9.5.23. |
…033 (comment) as well as possible workarounds" This reverts commit 744a796.
You do not have to wait for these new releases to add |
thanks to everyone involved. great to see a fast fix for this problem. great job! |
This is okay for me as long as the docs refelct this in a clear and visible way. |
Updating the documentation to reflect this change is the next thing on my TODO :) |
This works for me only if I have only one composer dependency with this “hack” installed. |
Perhaps add a link to this very issue in the error message for developers wanting more (background) information? Something like: Not impacted by this change myself, but it could give those impacted a bit more to go on :) |
sebastianbergmann/phpunit#5033 changed phpunit to no longer depend on phpspec/prophecy. This results in the need to add a development dependency for phpspec/prophecy. Doing so results in a warning, since PHPUnit\Framework\TestCase::prophesize() is deprecated and will be removed in PHPUnit 10. Let's use the trait provided by phpspec/prophecy-phpunit instead. * Fixes myclabs#177
sebastianbergmann/phpunit#5033 changed phpunit to no longer depend on phpspec/prophecy. This results in the need to add a development dependency for phpspec/prophecy. Doing so results in a warning, since PHPUnit\Framework\TestCase::prophesize() is deprecated and will be removed in PHPUnit 10. While we could use the trait provided by phpspec/prophecy-phpunit instead, it would break PHP < 7.3 support. * Closes php-mock#50
* Require phpspec/prophecy as dev dependency sebastianbergmann/phpunit#5033 changed phpunit to no longer depend on phpspec/prophecy. This results in the need to add a development dependency for phpspec/prophecy. Doing so results in a warning, since PHPUnit\Framework\TestCase::prophesize() is deprecated and will be removed in PHPUnit 10. While we could use the trait provided by phpspec/prophecy-phpunit instead, it would break PHP < 7.3 support. * Closes #50
we are using phpunit and don't use mocks. therefore we don't need phpspec/prophecy, which is a requirement for phpunit atm.
we would like to use phpunit on php8.2 but composer let us not install it because
phpspec/prophecy
seems to not yet support php 8.2.atm we can work around the problem using
--ignore-platform-req=php+
composer cli switch.I guess our situation is similar for other phpunit uses which also don't use mocks...
do you think its feasible to drop this dependency - or at least consider it optional in future phpunit versions?
thanks for the great tool.
The text was updated successfully, but these errors were encountered: