@Brontie Isn't it dangerous to just update the other packages by multiple versions at once? I think it might result in an explosion of errors if you miss some deprecation, or the deprecations are not managed perfectly by the maintainers. Usually, I revert the changes in my composer.json first, then upgrade the specific package and when that works correctly retry updating Symfony to make sure I can find out which package update is the source of problems which eventually arise. Did you know the composer outdated command, by the way? It shows very clearly what packages can be updated (major versions as well as smaller releases).
Isn't it dangerous to just update the other packages by multiple versions at once?
I guess it depends on how much test coverage you have ;)
As long as your vendor packages strictly follow semver and you use ^x.y version constraints in composer.json, theoretically, you shouldn't have a problem. But I get that, in reality, that isn't always the case.
In my experience, doing a composer update for all packages rarely breaks my apps. If it does, my test suite would (hopefully) fail.
When upgrading to new major versions of deps, I typically do what you describe (except for Symfony, which I upgrade to a new major all together).
Updating the other direct packages in one Composer run is the normal and safest move here, because Symfony’s upgrade blocker is usually a version constraint conflict, not a hidden runtime bug. Composer will stop on the first incompatible package and tell you exactly what needs to move, so you’re not blindly jumping over errors—you’re resolving them one by one until the dependency graph is consistent.
That’s why symfony composer outdated -D is so useful after the core upgrade: it shows the direct packages in your composer.json that can move to newer majors, like phpdocumentor/reflection-docblock, symfony/stimulus-bundle, and symfony/ux-turbo:
symfony composer outdated -D
In this chapter’s flow, the Symfony 8 upgrade is validated by the app booting, Turbo still showing AJAX navigation in the web debug toolbar, and Stimulus still initializing in the browser console. A useful gotcha: -D only checks direct dependencies, which is exactly what you want when deciding what you need to edit in composer.json.
Haha, I see that I should have watched the whole video before commenting, since composer outdated is mentioned directly after the moment I paused to write my reaction 😅
That’s the nice part of Composer-driven upgrades: the tooling tells you what’s actually blocking the move instead of forcing you to guess. composer outdated -D is exactly the command for spotting direct dependencies that have newer majors available, and in this upgrade it pointed to phpdocumentor/reflection-docblock, symfony/stimulus-bundle, and symfony/ux-turbo. Once those were bumped, the composer.lock update reflected the new resolved graph, and the app was then verified in the browser plus the Turbo/Stimulus checks.
5 Comments
@Brontie Isn't it dangerous to just update the other packages by multiple versions at once? I think it might result in an explosion of errors if you miss some deprecation, or the deprecations are not managed perfectly by the maintainers. Usually, I revert the changes in my composer.json first, then upgrade the specific package and when that works correctly retry updating Symfony to make sure I can find out which package update is the source of problems which eventually arise.
Did you know the
composer outdatedcommand, by the way? It shows very clearly what packages can be updated (major versions as well as smaller releases).Hey @tjveldhuizen!
I guess it depends on how much test coverage you have ;)
As long as your vendor packages strictly follow semver and you use
^x.yversion constraints incomposer.json, theoretically, you shouldn't have a problem. But I get that, in reality, that isn't always the case.In my experience, doing a
composer updatefor all packages rarely breaks my apps. If it does, my test suite would (hopefully) fail.When upgrading to new major versions of deps, I typically do what you describe (except for Symfony, which I upgrade to a new major all together).
--Kevin
Updating the other direct packages in one Composer run is the normal and safest move here, because Symfony’s upgrade blocker is usually a version constraint conflict, not a hidden runtime bug. Composer will stop on the first incompatible package and tell you exactly what needs to move, so you’re not blindly jumping over errors—you’re resolving them one by one until the dependency graph is consistent.
That’s why
symfony composer outdated -Dis so useful after the core upgrade: it shows the direct packages in yourcomposer.jsonthat can move to newer majors, likephpdocumentor/reflection-docblock,symfony/stimulus-bundle, andsymfony/ux-turbo:In this chapter’s flow, the Symfony 8 upgrade is validated by the app booting, Turbo still showing AJAX navigation in the web debug toolbar, and Stimulus still initializing in the browser console. A useful gotcha:
-Donly checks direct dependencies, which is exactly what you want when deciding what you need to edit incomposer.json.Sources:
Haha, I see that I should have watched the whole video before commenting, since
composer outdatedis mentioned directly after the moment I paused to write my reaction 😅That’s the nice part of Composer-driven upgrades: the tooling tells you what’s actually blocking the move instead of forcing you to guess.
composer outdated -Dis exactly the command for spotting direct dependencies that have newer majors available, and in this upgrade it pointed tophpdocumentor/reflection-docblock,symfony/stimulus-bundle, andsymfony/ux-turbo. Once those were bumped, thecomposer.lockupdate reflected the new resolved graph, and the app was then verified in the browser plus the Turbo/Stimulus checks.Sources:
"Houston: no signs of life"
Start the conversation!