[composer-based] Bond version-specific rules to composer package constraints - #979
Merged
Merged
Conversation
…traints Add config/sets/symfony/composer-based.php, a single set holding rules bound to the exact Symfony package version their target API was added in, mirroring the rector-phpunit composer-based set. Each rule declares its own constraint via ComposerPackageConstraintInterface, so it is registered once here instead of being repeated in every Symfony version set to cover a direct upgrade from an older version. Symfony has no single package to trigger on, so every package used inside the set registers it as a ComposerTriggeredSet, from the lowest version its rules require. Existing sets stay untouched.
Bonding a rule to a package only works when that package is installed, otherwise its test silently stops transforming. Keep composer.json as is and bond only rules whose package is already a dev dependency. Removes the symfony/messenger, symfony/twig-bridge and symfony/doctrine-bridge rules from the composer-based set.
Member
Author
|
First wave, let's ship to allow testing in core. |
This was referenced Aug 1, 2026
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
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.
Same shape as rector-phpunit #754 / #747, applied to Symfony.
What
A single new set,
config/sets/symfony/composer-based.php, holding rules bound to the exact Symfony package version their target API was added in. Each rule declares its own constraint:So the rule runs on any project with that package installed, no matter which Symfony version the upgrade started from - instead of only when the
symfony62set is picked.Effect
A project on
symfony/security-http6.4, upgrading from Symfony 5.4, gets the#[IsGranted]conversion without running the 6.2 set:And the same rule is skipped on a project still on
symfony/security-http5.4, where the attribute does not exist yet.Trigger
Symfony has no single package like
phpunit/phpunitto trigger on, so every package used inside the set registers it, from the lowest version its rules require:Notes
composer.jsonis untouched as well. A rule can only be bonded once its package is a dev dependency, otherwise the constraint filters it out and its test silently stops transforming. Rules forsymfony/messenger,symfony/twig-bridge,symfony/doctrine-bridgeandsymfony/framework-bundleare therefore left for a follow-up.symfony/console,symfony/twig-bundleandsymfony/security-core:rector/rector-srcrequiressymfony/console ^6.4.24and the root requiressymfony/config ^8.1, so those versions cannot be installed here at all.