How We Setup Our Laravel Projects

Laravel is an open source framework for the web. It provides a solid foundation for all kinds of web applications and is therefore our prime choice for new projects. With the newest version of Laravel released recently, we wanted to share our setup and some tips with you.

This series will be a mix of how we do things, our best practices, and some tips and recommendations. This article is for you if you are interested in the way we do things or if you are at the start of a new Laravel project and need some direction to orient yourself at.

With that being said, let's get started.

Setup #

First for every new project is the setup. Ever since multiple people worked on the same projects, there has been the issue of different environments. This was until docker and subsequently Laravel Sail arrived to save the day. For us at bitperfect, using containers is an absolute must for new and existing projects alike. From starting a new project to getting it set up and running on a new machine, containers and especially Laravel Sail streamlines the process and make it pain-free for everyone.

For all of you not knowing Sail: It is a combination of CLI-Tool and docker setup, tailored for Laravel and comes pre-installed since Laravel 8.

Our tip for a new setup is: don't overlook the Choosing Your Sail Services section on the installation page. Our defaults are PostgreSQL, Redis and we also like to add the devcontainer-flag for good measure:

curl -s "https://laravel.build/bitperfect-default-setup?with=pgsql,redis&devcontainer" | bash

This single command gets you all set up and started with a new Laravel installation. It does not get any easier than that.

Base config and common settings #

After setting up a new project, there are a few settings and options that we universally recommend in almost any project. In our checklist, you can find these things:

Enabling strict models #

One of the first things we tend to do in any new application is to add this single line to our AppServiceProvider:

Model::shouldBeStrict();

This simple line prevents three things on your models:

• Lazy loading of relationships
• Silently ignoring non-fillable attributes in mass assignments
• Accessing non-exisiting attributes

Why is this important, you might ask? Because it makes potential problems transparent to you.

For examples and additional information, Laravel News has an excellent article why you should use model shouldBeStrict when starting a new Laravel app.

Adjust the config #

By default, Laravel comes with a lot of default configuration and an extensive example .env file. These defaults do generally work well for most projects. However, some things that we like to adjust right away are:

• Changing the default app name to the actual app name in config/app.php
• Changing the default log channel to daily in config/logging.php
• Changing the cache driver to redis in config/cache.php (only if we use reddis in the project, obviously)

Generally, we like to keep all the things that should be the permanent default in the config files. That way, you keep the environment parameters slim and every environment parameter is something that changes the default by convention. Secrets are obviously an exception to this. Never add secrets to your config files!

Adding a code style fixer #

A consistent code style is important. It's even more important as soon as more than one person is working on a project. It not only prevents unnecessary bloat in form of whitespace changes in pull requests, but it also supports readability.

For us, tools that enforce certain code styles have long became standard for every project we work on. Our tool of choice has been prettier for a while now. It is easy to set up and works well for Laravel projects with the Prettier PHP Plugin. With Laravel Pint, there's also a Laravel-native option available.

We recommend using any code style fixer you like, as long as you use one. Bonus points if your CI pipeline checks the code style as well!

Adding a linter and a test setup #

Having static code analysis is another must have for our projects. For linting in Laravel projects, we have PHPStan with the LaraStan wrapper in our tool belt. This way we can easily catch problems with unused or dead code, unused variables, missing types,

For testing, we use the default setup exactly as it comes pre-packaged with the Laravel installation. Writing tests can seem like a lot of extra work at first, but trust me when I say, it's worth the extra effort in the long run. Updating your application with the confidence that nothing breaks brings peace to mind and a good nights sleep.

CI/CD Pipeline and Deployment #

Another thing we like to do and also recommend taking care of as early as possible in any new project, is setting up an automated pipeline for building, checking, testing and deploying the project. In our experience, setting this up early has two big advantages: First, you have a lot more time and runs to find and iron out any kinks in the process, as you would have if you'd set it up just before the go live. Secondly, you get immediate feedback if you try to do something that doesn't work in the pipeline or the deployment. This forces you to build good habit early for things like correctly managing your migrations, settings, environments, etc.

What we always include in our Laravel pipelines:

• Checking the code style (even if you set up auto formatting, in our experience sometimes things can go wrong and incorrectly formatted code makes it into the repository. The pipeline is an excellent guard for these cases)
• Linting
• Running the tests
• Deployment

For the deployment, we use a variety of hosters and services. In our experience, Laravel runs well in almost any environment. For our most recent projects, we started working with Laravel Forge and the Hetzner Cloud and can only recommend it so far. It makes setting up servers and sites, config and environment parameters, deployment, backups, queues and all the rest a breeze.