Chore(deps): Regenerate composer.lock on PHP 8.4 - #47
Merged
Conversation
Dependabot resolves against the composer.json PHP floor (^8.3), and Symfony 8.x requires php >=8.4.1, so #43 silently downgraded 22 Symfony packages from v8.1.x to the v7.4 LTS line. Regenerating on PHP 8.4.23 restores them and picks up the newer point releases. CI never reads composer.lock (test.yml runs composer update with explicit laravel/testbench constraints), so this only affects local development. Verified: 83 tests / 14030 assertions pass, PHPStan clean, Pint passes.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #43, which advertised three minor/patch updates but also downgraded 22 Symfony packages from v8.1.x to the v7.4 LTS line.
Why it happened
Dependabot resolves against the
composer.jsonPHP floor (^8.3), and Symfony 8.x requiresphp >=8.4.1. From a PHP 8.3 vantage point v7.4 genuinely is the newest installable Symfony, so the downgrade looked correct to the resolver. Regenerating on PHP 8.4.23 restores 8.1.x and picks up the newer point releases along the way.symfony/consolev7.4.17 → v8.1.6, and the same acrosshttp-kernel,serializer,string,yaml,routing,mime,uidand the rest of the 22.The genuine majors from #43 are unaffected and stay put:
guzzlehttp/guzzle8.1.0,guzzlehttp/psr73.1.0,hamcrest/hamcrest-phpv3.0.0.Scope
Lockfile only —
composer.jsonis untouched, so the supported PHP range is unchanged and consumers of the package are unaffected either way (a library's lock is never installed downstream).Worth noting the blast radius is small in both directions:
test.ymlrunscomposer updatewith explicitlaravel/framework/orchestra/testbenchconstraints and never readscomposer.lock, so CI was green on the downgrade and will be green on this. The lock only shapes local development — which is exactly why it's worth keeping honest, since nothing else will catch it.This will recur on the next grouped composer PR for the same reason. The durable options are raising the PHP floor (a breaking change, not proposed here) or re-running this regeneration when it happens.
Verification
Run locally on PHP 8.4.23 / Composer 2.10.2 against this branch:
composer test— 83 tests, 14030 assertions, OKcomposer static— PHPStan, no errorscomposer check— Pint, passedcomposer updatereported no security advisories