Invalid dependencies in ConfigProvider

[geerteltink]

There are some nonexisting classes in the ConfigProvider. Are they there for a reason?

https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L37-L39

https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L43

https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L55-L56

[michalbundyra]

I believe some of them are there only to make migration (from v2 to v3) easier. We used these classes before, and now we define aliases only. For example see: https://github.com/zendframework/zend-expressive/blob/master/docs/book/features/container/factories.md (this is at least about Delegate\DefaultDelegate)

[weierophinney]

I can vouch for each, and I'll explain them.

• The aliases (first quoted lines) exist for v2-v3 migration. Additionally, they allow the pipeline to use Zend\Expressive\Middleware\RouteMiddleware instead of Zend\Expressive\Router\PathBasedRoutingMiddleware which may be harder to remember.

• The ApplicationPipeline entry is because we likely do not want a shared MiddlewarePipeInterface or MiddlewarePipe service, but the application pipeline does need to be shared. This is a way to disambiguate.

• The two ServerRequest-related items are because these are returning PHP callables. I felt it was better to namespace them for uniqueness, and to give them context.