You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Incompatible package versions when loading with AWS SDK (for bedrock) #23
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.
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.
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.
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.
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??
Hey @CodeWithKyrian - feedback wise, this is would be valuable in the short-term. Without being able to implement league/oauth2-server, it's pretty difficult to use this package properly.
Enjoying it so far and fingers crossed this issue can be solved :)
Activity
holtkamp commentedon Jun 17, 2025
I also encountered this...
For documentation purposes:
psr/http-message ^1.0: https://github.com/aws/aws-sdk-php/blob/3.337.3/composer.json#L28psr/http-message ^2.0: https://github.com/aws/aws-sdk-php/blob/3.338.0/composer.json#L28I 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.0can be tracked here: reactphp/http#513CodeWithKyrian commentedon Jun 19, 2025
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-26update and this keeps getting in the way.I’ve thought about making
react/httpan 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 commentedon Jun 19, 2025
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 commentedon Jun 21, 2025
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??
micbenner commentedon Jul 31, 2025
Hey @CodeWithKyrian - feedback wise, this is would be valuable in the short-term. Without being able to implement league/oauth2-server, it's pretty difficult to use this package properly.
Enjoying it so far and fingers crossed this issue can be solved :)
27pchrisl commentedon Sep 1, 2025
I've just run into this trying to install
php-mcp/laravel. My solution so far is to put this in my application's root composer.json as a requirement:"psr/http-message": "2.0 as 1.1"It seems to have worked okay (checked with composer-diff)
joaquinwojcik commentedon Oct 13, 2025
Any updates on this @CodeWithKyrian ?