Essential Defaults to Configure for Your Next New Laravel Project

When starting a new Laravel project, the framework is already set up to help you hit the ground running quickly without much configuration. However, based on my experience, there are a few tweaks and configurations I like to make to tailor the setup to my workflow.

Disclaimer: These suggestions are pretty opinionated and might not fit everyone's needs. They've worked well for me, but feel free to adapt or skip them depending on your project or team requirements. Think of this as a starting point, and feel free to adjust them as needed.

Note also that they are features released with Laravel 12.

In this post, I'll share four things I tend to add to every new project I create. Whether you adopt them wholesale or use them as inspiration, they might save you a few headaches later!

Use Model shouldBeStrict

In the boot() method of the app service provider, add the global Model::shouldBeStrict(); declarative which can take a condition or not for evaluation. For instance, if the models should be strict in certain environments.

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    Model::shouldBeStrict(!app()->isProduction());
}

Under the hood, this method performs three functions.

1. It prevents lazy loading.
2. It prevents silently discarding attributes.
3. It prevents accessing missing attributes.

Note that each of these can be called in the boot method of the app service provider specifically on its own. Now, let's look at them in a little detail.

Preventing Lazy Loading

This basically helps us to prevent famous the n+1 query problem. Take for example.

$posts = \App\Models\Posts::get();
 
foreach ($posts as $post) {
     echo "<li>" . $post->title . "by" . $post->user->name . "</li>\n";
}

In the example above, we are performing an n+1 query. Because for every post, we are then going to perform an extra query to fetch the writer. With shouldbeStrict() turned on (or preventLazyLoading()), instead of running the code you'll get the following error:

Attempted to lazy load [user] on model [App\Models\Article] but lazy loading is disabled.

This is useful in development and test environments and can be corrected with eager loading as follows.

$posts = \App\Models\Posts::with('users')->get();
 
foreach ($posts as $post) {
     echo "<li>" . $post->title . "by" . $post->user->name . "</li>\n";
}

Preventing silently discarding attributes

In this case, an exception is thrown when we try to update an attribute that is not fillable. By default, Laravel will simply silently discard the request to update such column or attribute. For example;

$user->fill(["remember_token" => "bar"]);

Now, this will return an exception:

Add fillable property [remember_token] to allow mass assignment on [App\Models\User].

Preventing accessing missing attributes

In this case, an exception is thrown when we try to retrieve data from a non-existent database column or attribute. By default, Laravel will simply not display anything because the property is not found. This is really helpful to catch typos early in development. For example;

{{ $user->nonexistent }}

Now, this will return an exception:

The attribute [nonexistent] either does not exist or was not retrieved for model [App\Models\User].

Note that, it's fine to have these relaxed in production environment but activating the strict mode is great for development as it help could prevent you from making basic mistakes that could be harmful to the app later on.

Prohibit destructive database commands - specifically in Production

This is another important default to help prohibit a set of destructive commands that when ran, could result in data loss. This includes commnads such as php artisan db:wipe, php artisan migrate:rollback, php artisan migrate:fresh etc.. Although Laravel does have safeguards for these in production, if you really want to safe guard things, its a good idea to prohibit destructive commands entirely.

// app/Providers/AppServiceProvider.php
public function boot(): void
{
  DB:prohibitDestructiveCommands(app()->isProduction());
}

Enabling Carbon immutable date functionality - especially if you're working with dates in your app.

By default, Carbon dates are mutable. This can cause some sorts of confusion when we use methods like addHours(). The copy() method however, is a potential solution but you can be more productive by enabling carbon immutability by default in your app.

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    Date::use(CarbonImmutable::class);
}

Unguard models

This is a very opinionated one as Laravel guards the models by default, making the columns not mass assignable except they have been included in the fillable array i.e protected $fillable = [column1, column2]; or $fillable = false; or even setting protected $guarded = [];. I realized that I end up doing this in every model and in every app I've ever written and even though it takes less than 2 minutes to set up, it still is a repetitive task and I still forget to add it to some models - and have to deal with the exceptions when they come. To set this app wide, add the following to the boot method of the App service provider.

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    Model::unguard();
}

In conclusion, these are new Laravel features and for me, are must-haves for every new project I create. Let me know if you found these useful.