[DX] Depreate heavy and conflicting Symfony/Twig/PHPUnit level sets

[TomasVotruba]

It's not best practise to use UP_TO_* sets in rector.php longer than is their single-run. They run dozens of rules with very complex logic, as it take to get from Symfony 2 to 7. It's like running a Tesla control and checking all elements available since the first horse ride :)

Also, the tools we build upon - php-parser and PHPStan - traverse tree from top to bottom. That means if Symfony 4.4 changes a class, and then Symfony 3.4 changed a method, the changes would crash with each other.

We published post about this, but we should do more to have a DX that is useful and practical:
https://getrector.com/blog/5-common-mistakes-in-rector-config-and-how-to-avoid-them

The best practice - and we use it this way since the first Symfony rule set - to run those just once and remove 👍

Instead use only the latest major sets, to keep up to date and get fast and reliable Rector run 🚀

Thank you

• Resolves [ERROR] Rector timeout after upgrading it to 0.19.0 rector#8403
• Resolves add test cases for symfony forms in symfony 5.0 and 5.3 rector-symfony#547

[jackbentley]

This "best practice" is silly. If I'm running rector in CI then I want it to prevent known deprecated code from being introduced.

Changing from UP_TO_SYMFONY_54 to SYMFONY_54 will only find deprecations in that single minor release. Any deprecations in prior minor versions won't be checked. This means any new code which is deprecated in any version prior to the current can unknowingly get introduced.

The only way to make sure this new already deprecated code gets fixed is to run periodic UP_TO_* - which is not good as it will now include more changes than necessary.

Not to mention you've removed not deprecated the UP_TO_* functionality... This is not what deprecated means. If it was deprecated it would still work.

I agree running for example Symfony 3.3 rules on Symfony 5.4 is silly, unnecessary and intensive. You're essentially running fixes for code which is impossible to have implemented. What we actually need is sets which include fixes for all deprecations in the current major versions (if the package follows semver that is). For example, SYMFONY_5 to include 51, 52, 53 and 54 sets.

[TomasVotruba]

For example, SYMFONY_5 to include 51, 52, 53 and 54 sets.

I like this option 👍
How can we implement it to keep easy to maintain and setup in rector config?

[jackbentley]

If you're able to use glob patterns (or can enable it to be allowed) then you could set it up so the constant is pointed to all the sets in that version - for example, final public const SYMFONY_5 = __DIR__ . '/../../config/sets/symfony/symfony5*.php'; here https://github.com/rectorphp/rector-symfony/blob/main/src/Set/SymfonySetList.php

Worth mentioning an edge case might be someone running Symfony 6.1 when Symfony 6.2 is available with rectors. The rectors may add code which won't function. However, I'd expect in most cases people will be upgrading to the latest minor version at the same time as when they upgrade rector. Regardless such a feature is useful for running older versions like Symfony 5.4.

[samsonasik]

RectorConfig->import() no longer support fnmatch, see

rector-src/src/Config/RectorConfig.php

Lines 227 to 231 in f03a6fd

	if (str_contains($filePath, '*')) {
	throw new ShouldNotHappenException(
	'Matching file paths by using glob-patterns is no longer supported. Use specific file path instead.'
	);
	}

so if that needed, the collection of explicit paths need to be registered