How to make sure ray() won’t break your Laravel application with Github Action
The tools for improving developer experience continue to improve, which is great news. When it comes to debugging a Laravel application, as far as I know, there are still only two approaches:
- Xdebug, which offers step debugging based on "breaking points" and does not require modifying the source code
- "manual dumping," which allows you to display the contents of a variable but requires adding calls
The second method is pretty popular in Laravel community thanx to the famous dd() helper (that received some improvement in september 2022), but it has gained even more popularity recently since the release of the proprietary tool Ray (and its open source clones such as LaraDumps), which is based on a greatly improved version of “var_dump”. Ray has many advantages, including being really easy to set up. It only requires adding the package to your dependencies. But there are also some cons. The most annoying thing is that once debugging is complete, you have to remember to remove the calls that were added previously. And as you can imagine, it’s very easy to forget to do so.
As long as the environment on which you execute the code also installs Ray (with composer), these calls won’t trigger any error. So when you forget Ray calls in the code, it won’t really cause any problems. By adding Ray to Composer’s global dependencies, it will then be installed on your production environment:
composer require spatie/laravel-rayBut installing unnecessary packages in production is not a good practice at all. In some cases, this can impact performance, but there is also a risk that Ray may somehow expose sensitive information or include a bug or a security flaw. In cases where this risk cannot be accepted, Ray installation must be restricted to “dev” dependencies:
composer require spatie/laravel-ray --devAs soon as you do this, in addition to adding calls in the code, you must now also absolutely ensure that you have not forgotten to remove these calls once development is complete. You no longer have a choice. You can check this directly on the developer’s workstation, but as long as it is not automated, there will be a forgotten call someday. Automated tests do install “dev” dependencies, so forgotten ray() calls won’t trigger any error by themselves. You’ll probably face the problem directly in your production environment. Ray, which was supposed to help, then becomes a real problem and can break your application !
Therefore, the search for residual ray() calls must be automated, and this is generally integrated into a CI workflow. There are several tools that allow you to detect forgotten calls and trigger an error. Here are some of them:
- X-ray, a PHP package by Spatie themself that provide a dedicated binary
- a PHPStan rule (added in March 2023)
- the new architecture plugin from the Pest framework (since v2 released in March 2023)
- an Artisan command for LaraDumps
All of these solutions work well. But at Code16, we needed something more lightweight that:
- is quick to execute
- also detects forgotten Ray calls in Blade templates
- bonus if it has no dependencies
We came up with a simple and effective solution based on grep. By default, detection also includes migrations, tests, and routes. Since we use Github Actions for our CI, we included the script into an action directly available on the Github marketplace:
All you have to do is add these two lines to your existing workflow:
- name: Detect remaining Spatie\ray calls
uses: code16/detect-laravel-ray-action@v1There you go, you are now safe from remaining ray calls. The execution is very fast even for large applications.
As soon as a call is detected, the workflow will be interrupted and you will be alerted.
Try it, and feel free to give us some feedback. Happy debugging y’all !
