Curious about the next feature of Laracheck? Visit the Roadmap.
Do you have a feature request or want to report a bug? Visit the Request Board.
You can read about the motivation behind Laracheck In this article.
When you open a new PR Laracheck will run 10+ code checks and tries to identiy issues in your code. If it finds some issues it'll writ a comment on the PR: If everything is fine with your code it'll write a comment like this: So when you open a PR you should always see a Laracheck comment.
After you open a PR you probably will push more commits to your branch. These commits can also contain some issues. This is why Laravel runs after every push. After these pushes, it will only comment about new issues that didn't occur in your original PR. If no issues found there's no new comment.
Users, Collaborators, and Organizations
TLDR: Only the owner of the repository being checked has to have an account and active subscription.
If you want to use Laracheck on your personal GitHub account it's quite straightforward. Just register with your account, select a plan and you're good to go. You can have as many collaborators as you'd like to. Laracheck always checks the owner of the repository.
So let's say you subscribed to Laracheck with your jon.doe GitHub account and installed it to 10 of your repositories. Anyone who has access to these repos can open PRs and run the checks. It doesn't matter if the author of the PR is jane.doe since Laracheck will look for the owner of the repository and that is you, john.doe.
TLDR: Only one developer from the organization needs an account and active subscription.
When you install Laracheck you can choose any organization you're a member of. If the repository (that is being checked) belongs to an organization Laracheck will look for the person who installed the app on behalf of that organization. In this case, only this person has to have an account and active subscription.
TLDR: You can install Laracheck on any number of accounts or organizations.
After the installation, you'll see an aggregated list of repositories coming from multiple accounts and organizations. All the rules mentioned above still apply.
Since GitHub API has a rate limit, Laracheck will analyze only 50 files from each PR. The following files are excluded from every code check:
- Roue files
- Language files
- View files (such as blade or html)
N+1 query detection
Anytime you write a foreach loop or call a Collection method Laracheck will look for potential N+1 problems.
Here are the list of things that qualifies as a problem:
- You access a relationship that is not eager-loaded either in the body of the current function (using with() or load()) or in the model itself (using the $with property).
- You call DB functions in the loop such as DB::table()
- You call static Model functions in the loop such as Product::find()
- You call Model functions in the loop such as $product->save()
The current version of Laracheck requires you to have an app/Models folder where you store your models. Inside that folder you can have as many subfolders as you want.
For the time being, it won't detect N+1 problems in nested loops.
The following files are excluded from N+1 detection:
- View files (such as blade or html)
- Service Providers
- HTTP or Console Kernel
- Support files (typically helper function and classes inside app/Support)
Missing whenLoaded() calls
If you push an HTTP resource class we check if you used the whenLoaded() helper provided by Laravel. It's a great way to avoid N+1 and performance issues. The filename must end with Resource.php or the full path has to include Resources in order to trigger this check.
Missing DB index in migration
If you push a migration we check if you added any kind of index to new columns. The full path has to include migration in order to trigger this check.
Missing down method in migration
If you push a migration we check if it has a down method and it's not empty. The full path has to include migration in order to trigger this check.
Missing authorization in request
If you push a HTTP request we check if it has an authorize method and it's not return true. The filename must end with Request.php or the full path has to include Requests in order to trigger this check.
Validation in controller
If you push a controller we check if it uses any kind of validator. Usually it's a better idea to move this logic to a Request class. The filename must end with Controller.php or the full path has to include Controllers in order to trigger this check.
If your PR contains any changes related to PHP files we check if you wrote or modified tests as well.
Missing ENV variable
If you added a new key to one of your config file we check if you also included it in the .env.example file.
Missing/changed composer lock file
If you modified composer.json we check if you also pushed composer-lock.json. This way your production environment will have the dependencies as your local machine.
Any time your PR contains composer-lock.json as a change Laracheck will leave a comment so you can check it one more time that it only contains the necessary changes. Or you can ignore the comment if your task was to upgrade to Laravel 9 and you changed everything on purpose.
More checks and a public roadmap are coming soon, so stay tuned.
It's possible to instruct Laracheck to skip an entire commit. It's useful when you're working on a big feature and PR and you don't want to run the checks every time you push but only once or twice a day. To accomplish that add --skip-lc to your commit message, for example:
Add post migrations and models --skip-lc
In this case, none of the checks will run for any of your changes.
Skipping a Specific File
It's possible to instruct Laracheck to skip specific files. It's useful when you're working on a legacy class, for example. To accomplish that add this annotation anywhere to your file:
/** @laracheck-skip-file */
In this case, none of the checks will run for this specific file.