A roadmap towards Symfony 8 #43
Description
Currently, packages from the Behat ecosystem may be blocking projects from upgrading to Symfony 8.
One core issue is that Behat itself is using two interfaces from symfony/dependency-injection and symfony/event-dispatcher as part of its own APIs towards extension authors. Symfony 8 changed those interfaces to include return types. Declaring Symfony 8 compat in behat/behat would break Behat extensions that haven't done that change on their own code yet (cf. discussion Behat/Behat#1687).
The Behat team is currently planning a 4.0 release with the minimum changes possible to make it as easy as possible for extension authors to declare compatibility. The good news is that the Behat 4.x-dev branch as of commit bc90070 is in a state where you can Composer-install it ... as 3.99.99 or similar and get a Behat version that allows Symfony 8 components to be used, while still pretending to be using Behat 3.x. That of course only works as long as all extensions actually used have prepared for the necessary interface changes. Which brings us to this extension here.
Here we have two Listener classes and the Extension class itself that need to be prepared for the change (#37). Although these classes were probably never meant to be extension points, technically they are not final and so the change might in turn be considered a BC break for users that extend those classes. Soft-final-izing those classes and making the real change in the next major would be the clean way to solve that.
Since a new major release for that change alone might be considered overkill, here are two more reasons:
The Goutte library has been abandoned some time ago, and is currently restricting us here with regard to our own dev-requirements. So I think deprecating Goutte support and dropping it in a new major would be a good thing to do anyways.
A new major would be an opportunity to enforce return types for our interfaces and classes as well. This could be announced through #44, with the next major implementing the actual change.
As with Behat itself, a new MinkExtension major version would require downstream authors of MinkExtension-extensions to catch up as well. Two examples I am aware of are https://packagist.org/packages/dmore/behat-chrome-extension or https://packagist.org/packages/genesis/behat-fail-aid. Basically, those are packages that either register additional drivers/driver factories in our extension here, or that do something with the provided drivers. As long as such downstream packages are not using the Goutte driver or extending the final classes, the new major would mean they just need to amend their Composer requirements to include ^3.0. But, as long as they don't do, end users are still stuck.
Since downstream authors would rightly refuse to declare compatibility with a MinkExtension 3.0.0 release that does not yet exist, my suggestion is we try to come up with that release without waiting for Behat to see how they proceed.
By making final those classes that expose the problematic parts of the Behat API, we effectively shield ourselves from other changes that might potentially come up. In other words, I don't see how the changes you might reasonably expect to come in Behat 4 would justify yet another major release here.
POC, temporary workarounds
To experiment with this concept and to see if I can make it to Symfony 8 in my own projects, I created this branch with this series of commits in a personal fork of MinkExtension. You can get Behat + Mink + Symfony 8 to work with the following combination of dependencies:
- https://github.com/Behat/Behat/tree/4.x, use
as 3.99.99 - https://github.com/Kocal/FriendsOfBehat-SymfonyExtension/tree/symfony-8
as 2.99.99 - https://github.com/mpdude/MinkExtension/tree/move-forward
as 2.99.99 - If you use Symfony BrowserKit + Symfony HttpClient: https://github.com/minkphp/MinkBrowserKitDriver ^2.3.0 is compatible with Symfony 8