Back to Course |
[NEW] Laravel Project: From Start to Finish

Code Styling with Laravel Pint

Next, we will add a few more tools to the GitHub Actions automation: Pint and Larastan. We're looking at Pint in this lesson, but I want to say a few words on tooling in general.


Why Automation Tools in the BEGINNING? Why NOW?

At first glance, they may look like an overkill and unnecessary, especially for quite a small project we have here, but hear me out.

First, in this course, we're talking about processes that you would use on larger projects with larger teams and more strict client requirements. Those automation tools help to enforce the processes.

The second argument is that the beginning of the project is the best phase to add those automation tools. We have not written too much code so far, so it's easy to change it to satisfy the automation check requirements. If you try adding Pint/Larastan later in the process, you must fix many more code pieces. So, the earlier, the better.

Another goal of those tools is to establish habits. Those tools get you (and your IDE settings) into the rhythm of always writing code the recommended way. So, again, the earlier you adopt those habits, the easier it will be to follow those rules later in the project lifecycle.

The final argument is team coding standards. If you set them up correctly, all the current and future developers will know what rules to follow and avoid unnecessary code conflicts because some commas or spaces need to be in the right place.

Those standards are not set in stone, and they are not sacred rules. Each company/team may have a different set of rules. In fact, there are Laravel coding rules/standards/guidelines that some companies publish for others to see, like these:

Now, let's get to the practical discussion of Pint.


Code Styling with Laravel Pint

There are common questions from developers about how to style different code parts:

  • To add a comma after the last array item or not
  • To add a blank line between different parts of the Laravel class
  • etc.

Over the years, there were different answers: PSR standards and tools like PHP-CS-Fixer.

Laravel Pint was built on top of PHP-CS-Fixer and became the "official" standard solution for this. It is included in the Laravel installation via composer.json.

So, to ensure the code styling in the Laravel project, all we need to do is configure Pint and try to run it as part of GitHub Actions.

Again, we create a GitHub issue for this:

And a feature branch:

git checkout -b feature/laravel-pint

And then we add the pint.json file in the root folder of our Laravel project with the chosen preset:

pint.json

{
"preset": "laravel"
}

There are other presets like psr12.

Next, we may check our existing code style by running ./vendor/bin/pint locally, but instead, let's put it immediately as a GitHub Action.

So, a new .yml file to allow Pint to run in Parallel with PHPUnit:

.github/workflows/pint-check.yml

name: Check Code Style
 
on: [ push, pull_request ]
 
jobs:
tests:
name: Pint Check
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
 
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, bcmath, soap, intl, gd, exif, iconv
coverage: none
 
- name: Run composer install
run: composer install -n --prefer-dist
 
- name: Prepare Laravel Application
run: |
cp .env.example .env
php artisan key:generate
 
- name: Run Pint
run: ./vendor/bin/pint --test

The process is the same as with the Test run, but this time we call ./vendor/bin/pint --test instead of ./vendor/bin/phpunit.

And then we discover certain things in our code that were not written according to a recommended style:

For example, the spacing Issue looked like this:

Or there was a missing New Line:

After we fix those with another commit to the same feature branch, the Pull Request to dev becomes "green," and we can merge.

So, we needed to fix our styling only once, and from now on, GitHub Actions will automatically check the styling for us.

In the next lesson, we will examine another recommended tool for increasing the overall quality of code: Larastan.