With Guzzle v7, its class GuzzleHttp\Client became annotated as @final as it will be a real final class in Guzzle v8. Extending Guzzle clients to enrich them with custom functionality or to pass configuration (e.g. API credentials) is now discouraged and static code analysis tools like PHPStan may report this as an error. Depending on how GuzzleHttp\Client is extended, migration may be cumbersome. I got your back, and I'll cover some common cases in this blog post.

When implementing the fundamentals of my.typo3.org, an API based on Symfony was built to feed data to applications in the TYPO3 universe, e.g. the aforementioned my.typo3.org or the Certification Platform. This API must be rock-solid, thus it has a decent test coverage for each single piece gluing the application together. With development going further, the amount of tests increased, including API endpoints that get their data from a database. In out test scenarios, we use a sqlite database as this needs no additional setup.

In the recent release of TYPO3, namely 10.4.10 at the time of writing this blog post, a patch meant to improve the backend performance was merged: the introduction of SVG icon sprites. Unfortunately, this patch had unexpected consequences and lead to some new experiences.

Back then, when each browser had its own set and understanding of "supporting" JavaScript features, one knight in shiny armor saved us maiden developers and allowed us to focus on our tasks: jQuery. There was no necessity to remember every browser quirk or buggy implementation, jQuery was there and covered us.