webimpress/http-middleware-compatibility

Possible plugin improvement

Closed this issue · 6 comments

basz commented

A bit hard to explain; please read this thread. Are we doing something incorrectly. Should the plugin only look at the root dependencies? Or should we simple pin dependencies?

prooph/proophessor-do#149 (comment)

thanks!

michalbundyra commented

@basz
I've red through the thread and I think the main problem is that expressive does not support http-middleware 0.5.0 but zend-stratigility does. We had similar issue with zend-expressive, this is why version 2.0.5 has been released with pinned http-interop/http-middleware:0.4.1.

I can see two solutions for you:

  • pin http-interop/http-middleware:^0.4.1 (as you did)
    or:
  • pin zendframework/zend-expressive:^2.0.5

You can't support multiple versions of http-middleware (and the latest one) because expressive does not support it yet.

As you know, @weierophinney said we should have soon released zend-expressive with support http-middleware 0.5.0, but still we don't. Not sure, but maybe he is waiting for http-interop/http-request-handlers release. Then we need another update of our compatibility layer, but I hope it will be still possible to do smooth migration, without BC break.

basz commented

I see. thanks...

weierophinney commented

Not sure, but maybe he is waiting for http-interop/http-request-handlers release.

I am, because I'd like to have only one interim release where we support the various evolutions of the spec.

The plan within the working group is to finalize the spec, release the packages based on it, and then vote and start a review period, which is the final step prior to an acceptance vote. Towards finalizing the package:

  • We made the decision this week to only support PHP 7 and up, which leads to a change in signature as we now provide return type hints.
  • We remembered that part of the impetus to rename the delegate to a "request handler" was to allow shipping it standalone. As such, we will have two packages, with the middleware package depending on the request handler package. As such, the package name we consumer in Stratigility and expressive will change.

For the acceptance vote, we need two working implementations. As such, I really want our projects to be one of those, as we have a demonstrable ecosystem.

So, as such, I want to wait until those changes occurs so we can finalize how we support http-interopz but also do we can minimize impact for users once the spec is accepted.

basz commented

just noticed http-interop/http-middleware is now deprecated, over the released http-interop/http-server-middleware and i assume http-interop/http-request-handlers packages. @webimpress I'm curious, is it your intention to support those?

michalbundyra commented

@basz yes, I am working on it right now, please note there are some open issues in http-interop/http-server-middleware and http-interop/http-request-handlers which are kinda blockers for me, but I hope there will be merged today and released.

  • 👍1
basz commented

For the acceptance vote, we need two working implementations. As such, I really want our projects to be one of those, as we have a demonstrable ecosystem.

FYI This package is using the new interface already: https://github.com/middlewares/utils/blob/master/composer.json#L20-L21