feat: add ComposerPackageConstraintInterface

[calebdw]

Hello!

This PR introduces a new ComposerPackageConstraintInterface that allows individual Rector rules to specify a composer package constraint. Rules implementing this interface will be automatically skipped if the required package is not installed or does not satisfy the specified constraint.

Motivation

This is analogous to MinPhpVersionInterface (which skips rules based on PHP version) but for composer packages. This is particularly useful for framework-specific rules (e.g., Laravel, Symfony) where certain rules only make sense for specific package versions.

Comparison with ComposerTriggeredSet

Rector already has ComposerTriggeredSet for composer-based filtering, but it serves a different purpose:

	ComposerTriggeredSet	ComposerPackageConstraintInterface
Operates on	Sets (collections of rules)	Individual rules
Purpose	Auto-load upgrade sets based on installed version	Skip rules if package constraint not satisfied
Version matching	Caret (^) - targets specific major version	Any semver constraint (>=, <, ^, ~, ranges, etc.)
Use case	"Load Laravel 10 upgrade set if laravel/framework ^10 is installed"	"Skip this rule if laravel/framework doesn't match constraint"
Cumulative	No: each set targets a specific version range	Depends on constraint used

ComposerTriggeredSet is designed for upgrade paths where you want different sets for different version jumps (9→10, 10→11, etc.). ComposerPackageConstraintInterface is for rules that should only run when a package satisfies a specific constraint (for example, apply to a version and all subsequent version).

Usage

<?php
use Rector\VersionBonding\Contract\ComposerPackageConstraintInterface;
use Rector\VersionBonding\ValueObject\ComposerPackageConstraint;

final class SomeLaravelRector extends AbstractRector implements ComposerPackageConstraintInterface
{
    public function provideComposerPackageConstraint(): ComposerPackageConstraint
    {
        // Min version
        return new ComposerPackageConstraint('laravel/framework', '>=10.0.0');
        
        // Or max version
        return new ComposerPackageConstraint('laravel/framework', '<10.0.0');
        
        // Or specific major
        return new ComposerPackageConstraint('laravel/framework', '^9.0');
        
        // Or range
        return new ComposerPackageConstraint('laravel/framework', '>=9.0 <11.0');
    }
}

Thanks!

[TomasVotruba]

This looks like much lightweight than the cumbersome sets provider approach. Love it 🥰

Let's give it a go and test it. Thanks

[TomasVotruba]

I just noticed we have this feature in Rector... such an underrated power.

I'll have to tell my agents about it to flip all the Symfony/PHPUnit/Rector sets to this and just let Rector load the right rules automatically :)

[calebdw]

Yes! In my opinion, this kind of makes the composer sets obsolete. I've been meaning to update rector-laravel but haven't had time yet

[TomasVotruba]

Yeah, I wanted to make this happen, but was affraid of huge cognitive load to solve these.
Now I'll give it a go :) building on top giants - you've done epic work here 👏

My 1st trial to verify this works end-to-end is to upgrade to PHPUnit 11 and let Rector 1-shot the upgrade with 0 deprecations repoted by PHPUnit. (Watch live force pushes here on @mautic mautic/mautic#16891)

Single rule are easy to do now, but I've struggled with configured ones - e.g. some PHP 8 attributes were available on PHPUnit 10, some on PHPUnit 11 etc. So I made new config method to handle package + custom rules + version: #8244