Sometimes my clients need a specific CI check that spots tiny but annoying bugs, and they cannot be discovered by PHPStan, Rector, or coding standard tool. It can be unresolved conflict <<<<<<, invalid config syntax, or forgotten commented code.
Usually, we write specific PHP commands just for the particular project and let them rotten in spaghetti time. Instead, I cherry-pick those commands to a package called symplify/easy-ci. That way, I can use them in any project and improve them.
Today we'll look at 5 commands you can use in your CI. They might save you from bugs that no other tool can check.
To start, we first add the package:
composer require symplify/easy-ci --dev
PHPStorm is very good at renaming classes and methods. But its power stops at templates and configs, leading to bugs when the template contains a non-existing method. It can take days to discover this, as not everyone has tested and not everyone has I test that check every single render path of every template.
This command checks *.latte templates for:
{if App\Utils::validateUlr($url)}
...
<p>{App\ErrorMessg:VALID}</p>
{else}
...
<p>{App\ErrorMessage::NOT_VALID}</p>
{/if}
vendor/bin/easy-ci check-latte-template <paths>
# e.g.
vendor/bin/easy-ci check-latte-template app src
✅
This command is similar to the above. If PHPStorm or any developer renames a class, it can be missed in configs.
It checks all *.neon and *.yaml files for:
services:
-
class: App\SomeService
arguments:
level: App\Level::TOPP
vendor/bin/easy-ci check-config <paths>
# e.g.
vendor/bin/easy-ci check-config config
✅
How can we write the YAML syntax above in NEON? Very similar, but also in a much shorter way thanks to "NEON entities":
services:
- App\SomeService([App\Level::TOPP])
Do you understand this code? I'm not sure if it's interface, class, arguments of the method call.
This magic syntax also proven very hard to analyze with other tools. That's why we added a check to require explicit and straightforward code:
services:
-
class: App\SomeService
arguments:
level: App\Level::TOPP
It checks *.neon files to a magical inlined configuration that can be written explicit and transparent way.
vendor/bin/easy-ci check-neon <paths>
# e.g.
vendor/bin/easy-ci check-neon config
✅
Sometimes we merge old pull-request, and we have to rebase dozens of commits in the past. In 99 % of use cases, it goes well, or the CI reports a failure, but in 1 %, it hits us.
The price of this product is
<<<<<<< HEAD
0
=======
100
>>>>>>> branch-a
And then we have to explore how it got here, who added it etc. Why waste the energy if you can find this before merging?
Goes through all files and detects any unresolved <<<<<<< code.
vendor/bin/easy-ci check-conflicts <paths>
# e.g.
vendor/bin/easy-ci check-conflicts .
✅
Last but not least, sometimes, we temporarily comment out a chunk of code. We're testing something, or we don't need the method right now, so we comment it. Keeping commented code in main codebase is wrong for couple reasons:
git history and git blame to re-use old code.It goes through all *.php files and looks for lines of // commented code:
final class MoneyTransferer
{
public function run()
{
// @todo enable before merge
// if (! $this->ensureHasAccess()) {
// throw new ForbiddenAccessException();
// }
$this->sendMoney();
}
}
If there are 3 and more commented lines in a row, it will let you know.
vendor/bin/easy-ci check-commented-code <paths>
# e.g.
vendor/bin/easy-ci check-commented-code app src packages
Is the line limit too strict for your project?
Use --line-limit option to modify it to your needs:
vendor/bin/easy-ci check-commented-code app src packages --line-limit 6
✅
Happy coding!
Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors.
I'd really appreciate it!