The Bitbucket was dropped, as unused services and the demo repository is not maintained. The Travis was dropped, as it does not support open-source anymore and for private projects are better alternatives.
Are you doing code reviews? No? Yes?
In both cases, you won't have too. Just add a couple of YAML lines to your CI.
I'm very grateful that Rector is getting traction lately. More and more PHP developers save dozens of hours by running simple CLI commands on their codebases.
Just upgraded @phpunit from 4.0 to 8.4 with @rectorphp in 3 seconds with one command. It's worth knowing this tool. Thanks @VotrubaT 👏 pic.twitter.com/o3ESvJRsJ7
— Arkadiusz Kondas (@ArkadiuszKondas) November 18, 2019
It's a lot. But you want more laziness, right?
Rector can do much more without you even running it.
If you do code-review, what do you mostly do?
Look for patterns, explain them, report them everywhere or just somewhere and hope the other person will fix them all.
Discuss the design and why and what should be done about it.
Well, the 2nd cannot be automated, unless you're able to put it in clear step-by-step, e.g SOLID laws in procedural code. So you still have to do that, sorry.
But 1st step can be easily automated. How? Well, let's take a dead code for example. In the last project I've helped to improve with Rector, there were 2 years of dead-code piled up. A dead that you have to:
So many human-hours wasted. In the end, we removed over 12 % of "dead fat code". Wouldn't it be better if that fat would never be got it?
composer require rector/rector --dev
rector.php
config just for code-reviewsuse Rector\Set\ValueObject\SetList;
use Rector\Config\RectorConfig;
return function (RectorConfig $rectorConfig): void {
$rectorConfig->import(SetList::DEAD_CODE);
};
vendor/bin/rector process src --dry-run
I've prepared a demo with PHP code and a testing pipeline for all widely used CI services.
There you'll find all the configuration you need to let your CI do code-reviews.
# .github/workflows/php.yml
name: Rector Code Review
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
-
name: Validate composer.json and composer.lock
run: composer validate
-
name: Install dependencies
run: composer install --no-progress --no-suggest
-
name: Code Review
run: ./vendor/bin/rector process --dry-run
# .gitlab-ci.yml
# inspired from https://docs.gitlab.com/ee/ci/examples/php.html
# see https://github.com/RobBrazier/docker-php-composer
image: robbrazier/php:7.2
before_script:
# install composer dependencies for all stages
- composer install --prefer-dist --no-ansi --no-interaction --no-progress
stages:
- test
tests:
stage: test
script:
- vendor/bin/phpunit
code-review:
stage: test
script:
- vendor/bin/rector process --dry-run
Here are my favorite sets I apply first:
use Rector\Nette\Set\NetteSetList;
use Rector\Set\ValueObject\SetList;
use Rector\Config\RectorConfig;
return function (RectorConfig $rectorConfig): void {
$rectorConfig->import(SetList::CODING_STYLE);
$rectorConfig->import(SetList::CODE_QUALITY);
$rectorConfig->import(SetList::DEAD_CODE);
$rectorConfig->import(NetteSetList::NETTE_UTILS_CODE_QUALITY);
};
But you don't have to stop there. Pick any of 100+ sets that Rector provides.
That's it!
Oh... one more thing. You don't have to resolve all the Rector reported flaws manually, just remove the --dry-run
option and run it locally before pushing:
vendor/bin/rector process src
Enjoy your coffee!
Do you learn from my contents or use open-source packages like Rector every day?
Consider supporting it on GitHub Sponsors.
I'd really appreciate it!