Rule for safely prepare for upgrade to new version of PHP

[eduard-sukharev]

The pre-condition: the project uses PHP version it needs to migrate from. For the sake of discussion let's upgrade from 7.1 to 8.0.
The problem: While rector provides a broad set of useful refactoring rules which are helpful when you want to make your project be more up-to-date with all the blows and whistles of 8.0, it doesn't provide "a strict minimum" set of rules to apply before switching to new version. all I actually want is to safely upgrade and with minimal edits make sure the project won't break.
The solution: set of rules like UP_TO_PHP_80_BARE_MINIMUM to only fix those.

[staabm]

Your question highly depends on the codebase.

I would recommend adding a PHP8.0 PHPStan check, and pick rector rules based on the PHPStan errors you get

[eduard-sukharev]

but isn't rector supposed to be a tool to help one migrate easier to new versions of php? isn't easier imply safer?

[samsonasik]

You can do step by step, use LevelSetList::UP_TO_PHP_53 first, yes, start with lowest version, verify, repeat, exclude rule you don't want.

The rules you want to skip will always depends on your needs.

[rjmccluskey]

I agree with @eduard-sukharev. It would be nice to have a list of rules that only fix breaking changes between php versions. Or some way to easily parse those in documentation so I can create my custom list of rules.

[CViniciusSDias]

I also understand what @eduard-sukharev means. I would love to be able to run Rector on my PHP 7.2 project to upgrade it to 8.x, but only run the rules that are necessary for my code to run sucessfully.

I love the rules that improve and modernize my code, but on huge and older projects, if the number of changes is smaller, it's easier to get the project approved. :-)

[staabm]

You should always run one rule at a time. The Sets are actually only useful to reorganize the rector config file after you ran each rule individually (and you commit'ed and review'ed each rules changes individually)

[eduard-sukharev]

One rule at a time or all at once does not matter in this case: we seek for a set of rules for safe upgrade. We do not want to do the same manual "safe rule" set selection for each project. Yes, I am ok with running rule by rule, one at a time, but I would really love to have some predefined set of rules over which I would iterate. It's not like a set of safe rules forces us to apply them all at once, the same way UP_TO_* set of rules does not force us to apply them at once, but rather a convenient collection of rules to be applied.

[pedrogit]

Applying rules one by one is time consuming. So is searching for the only mandatory ones.

[gkakosouris]

This is a very sensible request. I would argue that it would greatly add to rector's usefulness with older, large codebases.

[skarnl]

This is exactly what I was expecting from Rector. Currently have a PHP7.4 project with Symfony 5.x - so want to upgrade that to the latest Symfony ... but that also needs PHP 8.x ...
So I was kinda expecting that Rector would only fix the deprecated and breaking stuff ... not also do all the fancy nice-to-have changes.

Would be nice to have a set ... or maybe just an option to only include necessary changes:

->includeFlags([NECESSARY & INCOMPATIBLE & BREAKING])

Something like that.
But ok - that would probably mean we will need to retroactive adjust all the sets and determine what's necessary 😁

[Cartman34]

Is there a list of those rules ? We need to list all required rules to migrate from 7.2 to 8.2 (or version one-by-one).

[DavidKuna]

@Cartman34 I'm looking for the same thing now. Did you manage to get/build the list? 🙏

[andrei-popa88]

Is there any update on this? It's exactly what I'm looking for!

[samsonasik]

Safe or not is always depends of project needs, philosophy, architectural, and personal preference, once we define the "safe" rules, other will argue that not that safe, so end up we are doing nothing :)

Run php sets one by one, step by step, and just skip that what you don't want :)

[eduard-sukharev]

Show me single person who would say "ChangeSwitchToMatchRector" is totally safe to apply to PHP 7.x codebase.

[eduard-sukharev]

Just in case anyone stumbles upon same issue and until there's a sensible inbuilt set, here's what worked for me when migrating from 7.4 to 8.2:

    // define sets of rules
    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_82,
    ]);

    $rectorConfig->skip([
        // custom project rules
        // ...

        // Do not apply 8.1 rules until we're on actualy php81 binary
        \Rector\Php80\Rector\FunctionLike\MixedTypeRector::class,
        \Rector\Php80\Rector\Switch_\ChangeSwitchToMatchRector::class,
        \Rector\Php80\Rector\Catch_\RemoveUnusedVariableInCatchRector::class,
        \Rector\Php80\Rector\Class_\ClassPropertyAssignToConstructorPromotionRector::class,
        \Rector\Php80\Rector\NotIdentical\StrContainsRector::class,
        \Rector\Php80\Rector\Identical\StrStartsWithRector::class,
        \Rector\Php80\Rector\Identical\StrEndsWithRector::class,
        \Rector\Php80\Rector\FuncCall\ClassOnObjectRector::class,
        \Rector\Php80\Rector\ClassConstFetch\ClassOnThisVariableObjectRector::class,
        \Rector\Php81\Rector\Array_\FirstClassCallableRector::class,
        \Rector\Php81\Rector\ClassMethod\NewInInitializerRector::class,
        \Rector\Php81\Rector\Property\ReadOnlyPropertyRector::class,
        // \Rector\Php81\Rector\ClassConst\FinalizePublicClassConstantRector::class, // this one was removed/renamed in rector
        \Rector\TypeDeclaration\Rector\ClassMethod\ReturnNeverTypeRector::class,
        \Rector\Arguments\Rector\FuncCall\FunctionArgumentDefaultValueReplacerRector::class,
    ]);

This was correct for Rector 1.2.x probably, for migrating from 7.4 to 8.2. Feel free to start from here and decide which rules are obsolete or should be added