Nyholm PSR-7 VS framework

As the documentation states, this package only performs the conversion, so we would need a PSR-7 and a PSR-17 implementation to convert the objects to and from PSR-7. We can use the library the documentation recommends, nyholm/psr7, but there are others.

The following example shows how to create configuration for the HTTP factories, using the nyholm/psr7 package:

Since the library is designed to be easily integrated with different frameworks, it relies on the usage of PSR-7 compliant HTTP messages. To fulfill this requirement, I'll be using the nyholm/psr7 package.

If you go strict PSR-7, as you see in nyholm/psr7, Tobias uses traits to add the functionality of the extended RequestInterface and MessageInterface:

The Symfony folks thought of this, however, and provided a bridge that converts HttpFoundation objects to PSR-7 ones. The bridge simply needs a PSR-7 and PSR-17 factory, for which they suggest to use Tobias Nyholm's PSR-7 implementation.

“In theory, theory and practice are the same. In practice, they are not.” (Dr. Albert Einstein). I believe same goes for packages, too. A good example is the [comparison](https://github.com/Nyholm/psr7) of some PSR-7 implementations.

The point is why would I pull in code in the first place that is not needed? If it is optional, then why is it not a separate package? Same with all of the bloated HTTP requests and response objects that frameworks and other libs usually use. I really like https://github.com/Nyholm/psr7 for that reason, it has a table in it's readme.md that is pretty much enough to know why I like it. If something specific is needed it can be decorated or extended on project level.

In April of 2021, version 1.0 of FEAST Framework was released. One year ago, version 2.0 of FEAST Framework was released. Today, I am happy to announce the release of version 3.0 of FEAST Framework.

I would like to submit https://github.com/feastframework/framework to this. It's a small framework I wrote and what I think sets it apart is it has 100% code coverage with PHPUnit and has 100% static type analysis with psalm.

FEAST Framework. Go figure.

This isn't quiiiite the same as your scenario, but in December the (not yet at that time) version of FEAST Framework didn't have a single unit test outside of one simple class (The Date class). By March, it had 100% coverage.

You can find it here: FEAST Framework

I have minor issues with the PSR-11 interface due to it not being capable of strong typing on the variables... And yet my framework (https://github.com/feastframework/framework) uses it. It's nice to have that layer of flexibility. Admittedly, I pissed a few people off by just throwing the interface in my codebase but whatevs 😂

This book actually had a very large hand in the development of my PHP Framework FEAST and definitely is one of the books that inspired my goal (which was achieved) of 100% code coverage.