Since Rector 0.12 a new RectorConfig
is available with simpler and easier to use config methods.
More than 45 days have passed since the last Rector release. Since then, we pushed 292 commits in over 220 pull-requests. No wonder the most common question in issues was "when will the next Rector be released?".
Today, we're proud to finally tag and launch Rector 0.9!
The most awaited feature is upgrade set to PHP 8. We already wrote Smooth Upgrade to PHP 8 in Diffs - with promoted properties, annotations to attributes, union types, and more.
We tested this set for the last 30 days, solved bugs one by one, and applied in CI on 5 PHP projects.
How does it perform?
That feeling when you go to make coffee,
while @rectorphp upgrades your project in PHP 8...
Do you want to upgrade to PHP 8? It's ready!
use Rector\Set\ValueObject\SetList;
use Rector\Config\RectorConfig;
return function (RectorConfig $rectorConfig): void {
$rectorConfig->import(SetList::PHP_80);
};
The PHAR file is a file that contains PHP code in a single RAR file, thus the PH+AR acronym. Working with PHAR in PHP has it's edge cases. Do you use a real path? realpath in PHAR does not work. Everything has to be relative to some PHAR root. Another bunch of bugs happen in Symfony, thanks to glob
and slash juggling. The PHAR itself caused over 143 issues so far.
Rector is designed to work with the worst code possible. It's improving on every release but still fails with a fatal error on new edge cases that we haven't thought of.
How would you debug a line in prefixed Rector? Simple and fast dump()
on the broken line? But, how can we edit a RAR file? It's not possible to do directly. First, we need to unpack the file, edit it, then pack it again. The same rules apply for PHAR.
We want to make working with Rector in legacy projects more accessible. That's why we're moving to scoped version.
Install path remains the same:
composer require rector/rector-prefixed --dev
But now you can also:
dump()
/vendor
PHP 7.2 is out of maintenance November 30th, and dangerous to use. That's why the minimal version for Rector was bumped to 7.3.
Why would anyone want to downgrade code? What a silly question, right?
There is one use case that every package maintainer is thinking about. We want to develop in the latest PHP - PHP 8. But our composer.json
also allows PHP 7.3 and 7.4. Why? Because we don't want to leave the PHP community behind.
This will soon be possible on a CI basis. Today, you can code in PHP 7.4 and deploy to 7.1 via GitHub Actions.
Now the fun part comes. We have downgrade sets, and we moved from PHAR to Scoped. This switch not only solves edge cases and Docker mashup with relative/absolute paths but also opens the door to per-PHP version releases. Do you need Rector for PHP 7.1 without Docker?
composer require rector/rector-php71 --dev
composer require rector/rector-php70 --dev
composer require rector/rector-php56 --dev
The floor is the limit.
We're working on it. Stay tuned!
Do you want to try a new version but fear changes? Check UPGRADE_09.md
for specific steps and go for it:
composer update rector/rector:^0.9
Last but not least, we'd like to thank all 0.9 contributors that put their keystrokes together as one.
Thank you @samsonasik, @leoloso, @simivar, @staabm, @Wirone, @HDVinnie, @lulco and @JanMikes.
Happy rectoring!