Add a way to override a part of a SetList

[soullivaneuh]

Feature Request

The request come from an issue I found concerning a too more aggressive rule from the Symfony 4.3 ruleset: rectorphp/rector-symfony#390

At the end, you said it is not possible followed by:

The best practice is to use those sets only for upgrade, not in long-term.

I personally don't agree with that. The rector tool is also meant to be used as a CI job. It is very useful to prevent the usage of deprecated but still available class on future contributions of a project waiting the upgrade to be done, especially for the big ones.

I also tried adding the reverse rule:

$rectorConfig->sets([
    SymfonySetList::SYMFONY_43,
    // ...
]);
$rectorConfig->ruleWithConfiguration(
    RenameClassRector::class,
    [
        'Symfony\Contracts\Cache\CacheInterface' => 'Psr\SimpleCache\CacheInterface',
    ],
);

But as I expected, it end into an infinite loop of the tool.

Can we consider a way to partially include/adjust a give set list?

Regards

[TomasVotruba]

Hi, thanks for proposal. Instead of add configuration to remove configuration, the better solution is to avoid such setups in the first place.

I realize using full Symfony 2 to 7 sets is a non-sense that leads to logical conflicts like this one. Such huge all-in-one sets also disables reverts. E.g. Symfony 4 adds a features, Symfony 6 reverts it. Having 2 rules for each this case would create an infinite loop. In practise it's standard to go up one version at a time. Even legacy projecs are upgraded one Symfony major (better minor) version at a time to deal with all transitional changes.

Saying that, using level sets will be removed and standard single-version sets should be used instead.

More mentioned here:
rectorphp/rector-src#5477

[TomasVotruba]

As for the rectorphp/rector-symfony#390 - I've missunderstood the original request.

Here is a fix rectorphp/rector-symfony#574

Thanks for bringing that up 👍