You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since PHPUnit 10 is dropping this repo is back to live. But unfortunately, this reintroduces an issue that we had in phpDocumentor for years. prophecy is using some of our core libraries which is perfectly plausible but this causes issues when testing those libraries with our preferred mocking framework ❤️
We were facing 2 issues:
circular dependencies, preventing us from installing PHPUnit via composer and prophecy.
PHP loads classes by namespace only once. Which caused all kinds of odd issues during our unit tests. Like testing the wrong subject.
A few releases ago PHPUnit started shipping a scoped phar which recompiles the PHPUnit extensions into a PHPUnit specific namespace. This awesome move finally gave us the option to install PHPUnit without any hacks and issues. Stabilizing our ci pipeline.
Now PHPUnit 10 will drop build-in prophecy shipping these issues will most likely come back. So I started investigating a workaround, which I found. PHPUnit supports loading extensions from phar files. together with phar.io this would be a very nice solution to install prophecy as a PHPUnit extension in a scoped phar.
How it works
Following the example extension I could create a phar file which is loaded by PHPUnit. I could provide an example phar, but it is useless right now because PHPUnit still ships prophecy so classes will conflict. The "only" thing to do would be to create a manifest and set up the scripts to be able to build a phar for each new release.
If you understand my problem, I would like to hear if you are interested in some GitHub action scripts that will automate the process of creating a phar for each release.
Disclaimer
I'm not aware of any other projects facing this issue, but I think in general shipping development tools in isolation makes sense. phar.io is under development. But I think this could be the new revolution in PHP dependency management. Since it solves a number of issues that cannot be solved by composer. Like the described issues above. But also for applications that are not able to upgrade dependencies but would like to move forward with their toolchain to keep up.
Besides that, I do fully understand that you might not have the time to maintain the creation of the phar. That's why I'm offering my support for just this part.
The text was updated successfully, but these errors were encountered:
Hi,
Since PHPUnit 10 is dropping this repo is back to live. But unfortunately, this reintroduces an issue that we had in phpDocumentor for years. prophecy is using some of our core libraries which is perfectly plausible but this causes issues when testing those libraries with our preferred mocking framework ❤️
We were facing 2 issues:
A few releases ago PHPUnit started shipping a scoped phar which recompiles the PHPUnit extensions into a PHPUnit specific namespace. This awesome move finally gave us the option to install PHPUnit without any hacks and issues. Stabilizing our ci pipeline.
Now PHPUnit 10 will drop build-in prophecy shipping these issues will most likely come back. So I started investigating a workaround, which I found. PHPUnit supports loading extensions from phar files. together with phar.io this would be a very nice solution to install prophecy as a PHPUnit extension in a scoped phar.
How it works
Following the example extension I could create a phar file which is loaded by PHPUnit. I could provide an example phar, but it is useless right now because PHPUnit still ships prophecy so classes will conflict. The "only" thing to do would be to create a manifest and set up the scripts to be able to build a phar for each new release.
If you understand my problem, I would like to hear if you are interested in some GitHub action scripts that will automate the process of creating a phar for each release.
Disclaimer
I'm not aware of any other projects facing this issue, but I think in general shipping development tools in isolation makes sense. phar.io is under development. But I think this could be the new revolution in PHP dependency management. Since it solves a number of issues that cannot be solved by composer. Like the described issues above. But also for applications that are not able to upgrade dependencies but would like to move forward with their toolchain to keep up.
Besides that, I do fully understand that you might not have the time to maintain the creation of the phar. That's why I'm offering my support for just this part.
The text was updated successfully, but these errors were encountered: