Composer platform requirement conflicts after the PHP 8.5 upgrade
Bumped a service to PHP 8.5 in the container and now composer update refuses to resolve, complaining that several packages require php greater than or equal to 8.1 and less than 8.5. The packages clearly run fine on 8.5, the constraint is just a conservative upper bound the maintainers set and have not relaxed yet. I do not want to fork half my dependency tree.
What is the clean way to move forward without lying to Composer in a way that bites me later? I know about config.platform but I am not sure where the line is between pragmatic and dangerous.
config.platform.php in composer.json tells Composer to resolve as if you are on a specific version, regardless of the actual runtime. Set it to your real target and resolution uses that. But it does not override a package that hard-caps php below your version, it just pins what Composer assumes the platform is. For the upper-bound caps you need a different tool.
For conservative upper bounds the right tool is composer-patches or, simpler, an inline alias or the extra.composer-exit-on-patch-failure is not it. What you actually want is to relax the constraint without forking: use composer why-not php 8.5 first to see exactly which packages block you. Often it is one transitive dependency, not the ten you think, and that one may already have a tagged release that lifts the cap.
why-not is the command to start with, agreed. If the blocking package genuinely has no compatible release yet, an inline alias in your root composer.json can map a working commit to a version that satisfies the constraint, but that is a sharp tool and you must track upstream and remove the alias once they release. Document why the alias exists right next to it or future you curses present you.
why-not php 8.5 narrowed it to exactly two packages, not the wall of errors composer update threw. One had a newer tag that already supports 8.5 and I was just behind, updating it cleared most of it. The other I aliased a recent commit with a note and an issue link. config.platform stays at the real 8.5 so I am not hiding the target from CI. Much cleaner than I feared.
Whatever you do, keep config.platform.php honest to what production actually runs. The dangerous pattern is setting platform to 8.1 so everything resolves while your container is 8.5, then a package quietly uses an 8.5-only function and it works in prod but your locked tree was resolved for 8.1. Resolve for the version you deploy, and fix the upper-bound caps explicitly rather than by lying about the platform.
```php blocks are runnable.