Rector is a tool for automatic code refactoring. ECS allows keeping coding standards in the project. From few days, configuration of both tools is more developer friendly.
About #Rector and #ECS I’ll write several times for sure because these are extraordinary tools. But for now I wanted to focus on one refreshing change that was added recently.
Historical context
Since both of these tools use symfony/dependency-injection
under the hood, for a long time they were forced to operate within API exposed by this component, because many of its classes or methods are marked as final
and don’t allow extending nor overriding. Everything has changed when Rector implemented architecture based on development repository and so-called “prefixed” one, which is the result of automatic refactoring and downgrading… with Rector 😉 Such approach opened many new possibilities and authors took this chance by patching Symfony components, covering their original API with custom one.
API changes genesis
While using Rector, at some point I had a problem related to tool configuration in terms of #static-analysis, so I’ve started discussion which resulted in my Pull Request. In the end it wasn’t merged, but it became base for actual changes in API, introduced by the author, Tomas Votruba. As he said himself, my idea opened new universe of options 😅
Old vs New
Changes in API are not revolution, but nice evolution. Before, you had to configure like this:
use Rector\Core\Configuration\Option;
use Rector\Php74\Rector\Property\TypedPropertyRector;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
return static function (ContainerConfigurator $containerConfigurator): void {
$parameters = $containerConfigurator->parameters();
$parameters->set(Option::PARALLEL, true);
$parameters->set(Option::AUTO_IMPORT_NAMES, true);
$services = $containerConfigurator->services();
$services->set(TypedPropertyRector::class);
};
After changes instead of using Symfony’s configurator, custom Rector configurator is available:
use Rector\Php74\Rector\Property\TypedPropertyRector;
use Rector\Config\RectorConfig;
return static function (RectorConfig $rectorConfig): void {
$rectorConfig->parallel();
$rectorConfig->importNames();
$rectorConfig->rule(TypedPropertyRector::class);
};
Similar changes were introduced in ECS, of course its API is slightly different than Rector’s, but in general it’s all about the same idea — using custom configurator methods instead of too general $containerConfigurator->parameters()->set()
.
Easter is coming... have you find the easter 🥚 ? pic.twitter.com/tF39Xqgy0N
— Tomas Votruba (@VotrubaT) April 14, 2022
My proposal of simpler ECS API
Personally, I’ve switched to new API really quickly, but while working with ecs.php
I discovered that new API exposes 2 methods for adding rules: rule()
and ruleWithConfiguration()
. In my opinion it’s cumbersome, so I’ve created Pull Request with proposal of simplifying API. Unfortunately it was rejected, though I don’t agree with provided reasoning 😉
What do you think?