Incompatible package versions when loading with AWS SDK (for bedrock)

[marcelfolaron]

I am using AWS Bedrock for LLM calls and various other functions and starting with 3.338 they require psr/http-message ^2.0 however the php-mcp server requires react/http ^1.11 which in turn requires psr/http-message ^1.0 which is not compatible with the 2.0 requirement above.

Not sure if there are options to provide compatibility since I know the culprit is on the ReactPHP side but the AWS SDK is now at version 3.346 and there are some important updates in there.

Thank you!

[holtkamp]

I also encountered this...

For documentation purposes:

• last version that also allowed psr/http-message ^1.0: https://github.com/aws/aws-sdk-php/blob/3.337.3/composer.json#L28
• first version that only allowed psr/http-message ^2.0: https://github.com/aws/aws-sdk-php/blob/3.338.0/composer.json#L28

I think this is quite rigid, since https://www.php-fig.org/psr/psr-7/meta/#72-type-additions suggests that support for "psr/http-message": "^1.1 || ^2.0" would have been a viable approach for https://github.com/aws/aws-sdk-php as well, but that is probably too late now...

Final note: support for psr/http-message ^2.0 can be tracked here: reactphp/http#513

[CodeWithKyrian]

Yeah, I’ve run into this too and it’s honestly been frustrating, especially since I’ve been working on adding OAuth support in line with the MCP 2025-03-26 update and this keeps getting in the way.

I’ve thought about making react/http an optional or dev dependency to let users choose, but that still pushes the problem downstream and doesn’t fully solve it.

I’ve been following the activity on reactphp/http, and there's been more interest in v2 support lately (which is a good thing at least). I’m thinking of reaching out to @clue directly to get a sense of what’s planned or how we might move things forward there.

Open to better ideas though. If anyone’s figured out a clean workaround or has thoughts on a future-proof approach, I’d really love to hear.

[marcelfolaron]

So to unblock our work I went ahead and temporarily forked reactphp/http as well as php-mcp with the PR #543 merged in. Composer let's you override the library with the same name by defining the repository in your composer file. Everything works. We don't use reactphp in any other capacity so it works for us.

My updated composer is here:
https://github.com/Leantime/leantime/blob/9e7dda0b2fe6bdc581b24bf5a977c3eff0549a7e/composer.json#L104
and https://github.com/Leantime/leantime/blob/9e7dda0b2fe6bdc581b24bf5a977c3eff0549a7e/composer.json#L163

It's fairly simple to go back to the original libs when the updates are in. Feel free to use the forks I will keep them up until psr/http-message 2.0 support is in.

https://github.com/Leantime/php-mcp-server
https://github.com/Leantime/reactphp-http

This works for now since we are going to be in beta anyways.

[CodeWithKyrian]

Thanks @marcelfolaron, your fork approach is smart and technically it works in practice.

Honestly, I've been going back and forth on this. Part of me wanted to just do this - fork, publish on Packagist, keep it synced with upstream until they sort out PSR-7 v2. But I've been hesitant because, well, it feels a bit weird forking someone else's work just to unblock this, plus the maintenance overhead.

But people need to actually use the package and rather than being stuck, might just bite the bullet and do it properly. Not thrilled about it, but seems like the path of least resistance at this point. Maybe? What do y'all think??