chore(deps-dev): update rector/rector requirement from 2.5.9 to 2.6.1 in the composer-dependencies group

[dependabot]

Updates the requirements on rector/rector to permit the latest version.
Updates rector/rector to 2.6.1

Release notes

Sourced from rector/rector's releases.

Released Rector 2.6.1

Bugfix 🐛

• [composer-based] Fix fatal error in the composer-based command on a lazy-initialized property, e.g. PHPStan UnionType::$normalized (#8280)

PHP Fatal error:  Uncaught Error: Typed property PHPStan\Type\UnionType::$normalized
must not be accessed before initialization in src/Console/Command/ComposerBasedCommand.php:205

---

Composer-based sets keep growing: Twig, nette/utils and the rest of Symfony 📦

Follow-up release to 2.6.0. The composer-based rollout continues - Twig and nette/utils join, and every remaining Symfony rule now declares the package version its target API was added in.

use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withComposerBased(
doctrine: true,
netteUtils: true,
phpunit: true,
symfony: true,
twig: true,
);

The new Twig composer-based set replaces the twig112 → twig127 → ... → twig30 chain with a single set, where every rule checks the installed twig/twig version:

 final class SomeTwigUse
 {
-    public function run(Twig_Environment $twigEnvironment)
+    public function run(\Twig\Environment $twigEnvironment)
     {
-        return new Twig_SimpleFilter('some_filter', 'strlen');
+        return new \Twig\TwigFilter('some_filter', 'strlen');
     }
 }

Package bonding (composer-based rollout) 📦

• [NetteUtils] Bind nette/utils rules to the installed package version; nette-utils4.php becomes composer-based.php and is loaded as a single set (#8275)

... (truncated)

Commits

• b8e68f0 Rector 2.6.1
• 8d4664e Updated Rector to commit 16be33c1c2364d51038752a299fce01043d42576
• 834ed36 Updated Rector to commit 4e11a4088c0634076742b71dc9db4cfbeab4a207
• 77f9eec Updated Rector to commit 4e11a4088c0634076742b71dc9db4cfbeab4a207
• 55176b4 Updated Rector to commit 4e11a4088c0634076742b71dc9db4cfbeab4a207
• c529f35 Updated Rector to commit 72f8056755dc28dd1a8ab8f39900259f129ebae8
• 080ed0f Updated Rector to commit 72f8056755dc28dd1a8ab8f39900259f129ebae8
• 30c1e33 Updated Rector to commit 72f8056755dc28dd1a8ab8f39900259f129ebae8
• 8e262e1 Updated Rector to commit 952266b6d64f923f9d6d4390e423e4ab65a953c6
• 2ca9c01 Updated Rector to commit da48be85d84c065d1f018c9074694980d2351e77
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[michalsn]

@samsonasik, any recommendations on how we should handle deprecated rules? Is simple removal okay, or should we migrate?

[samsonasik]

@michalsn if the rules are useful for us, I think we can copy the original rule into utils/src/Rector, or probably better, create new repo for rules that useful for us.

If the rules are not useful for us, clean up is ok.

[paulbalandan]

Just want to add. I cloned this locally trying to fix the red. I followed rector's suggestions to delete those skips since it says those are not reached. However, upon removing the skips, those get applied instead. So, its claim is false.

[michalsn]

Thanks @samsonasik. The question is: should we leave it here or eventually introduce it into our CS, since this is more of a coding-style preference and that's why it was deprecated? My preference is to move it into the CS rules, but I'm not sure how hard it would be. As I understand it, the schema for this was "simple":

count($array) === 0  // $array === []
count($array) > 0    // $array !== []
! count($array)      // $array === []

@paulbalandan any thoughts? TBH, I'm also fine with just removing it and calling it a day.

[samsonasik]

comparing to === [] is faster actually, see our original discussion #3839 (comment)

[michalsn]

I followed rector's suggestions to delete those skips since it says those are not reached. However, upon removing the skips, those get applied instead. So, its claim is false.

Yes, those skips have to stay.

[paulbalandan]

I think that should go and reintroduce it as a CS rule. I can look at it later.