How to deal with patched ContainerConfigurator on end project's side?

[Wirone]

Rector patches ContainerConfigurator, so it's shipped in prefixed release with modified signature. The problem appears when you need to configure rector, like this:

<?php

declare(strict_types=1);

namespace Foo\Rector\Sets;

use Foo\Rector\Rule\SomeRule;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;

return static function (ContainerConfigurator $containerConfigurator): void {
    $services = $containerConfigurator->services();

    $services
        ->set(SomeRule::class)
       // Method 'configure' not found in \Symfony\Component\DependencyInjection\Loader\Configurator\ServiceConfigurator
        ->configure([])
    ;
};

When prefixed (patched) ContainerConfigurator is imported instead of Symfony one it works and does not report error, but since prefixed namespace differs between releases it would require modifying such file after each Rector upgrade.

How to properly deal with it? Is it possible to re-work Rector architecture to provide valid API? As far as I understand configure() was introduced to be able to change rectors' behaviour without using __construct() which is used for autowiring. But as you can see here it affects end users' DX since there's no support for ContainerConfigurator::configure().

[TomasVotruba]

The only way could improve this, is if the ServiceConfigurator would be extendable. Unfrotunatelly, the method is final on Symfony's side, so we have to hack around like this.

If you find a better way without breaking current API, I'm all ears.

[Wirone]

@TomasVotruba Actually I had something different in mind but wrote that without looking at the code, my bad 😉 I wanted to say that Rector could provide something like:

<?php

namespace Rector\Core\DependencyInjection\Loader\Configurator;

class RectorContainerConfigurator extends \RectorPrefix20220117\Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator
{
}

so in the end project RectorContainerConfigurator could be used as stable alias for prefixed & patched Symfony's configurator:

<?php

declare(strict_types=1);

namespace Foo\Rector\Sets;

use Foo\Rector\Rule\SomeRule;
use Rector\Core\DependencyInjection\Loader\Configurator\RectorContainerConfigurator;

return static function (RectorContainerConfigurator $containerConfigurator): void {
    $services = $containerConfigurator->services();

    $services
        ->set(SomeRule::class)
       // Result of `RectorContainerConfigurator::set()` is `RectorServiceConfigurator` which has `configure()` API
        ->configure([])
    ;
};

If Symfony decided to change ServiceConfigurator class to final you could change patch and remove it 😉 I did PoC locally and it looks like it could work.

[TomasVotruba]

That looks good 👍

How would we explain the ambiguity for 2 Container Configurators? That's what we want to avoid in the first place. The configs should be 1:1 to default Symfony.

[Wirone]

IMHO it doesn't need to be 1:1 Symfony implementation. It's standalone tool, may provide its own API, even if mostly based on Symfony's. You need additional way for configuring, you provide it, that's how it looks. And it's better than missing API that cause trouble for static analysis 🙂

[TomasVotruba]

Allright :) let's send the implementation 👍

[Wirone]

@TomasVotruba implementation in rectorphp/rector-src#1891

[TomasVotruba]

Your idea took me to a new univers of options 😃 👍

Final solution could be custom class with own method:
rectorphp/rector-src#2019