This post will show you how to customize stubs used to generate various classes in your application. While a minor inconvenience, manually adjusting every generated class can be tedious, and Laravel provides a way for developers to publish and version stubs in an application if you want to suit generated classes to your specific taste.

If you want to follow along, you can create a new Laravel project with the Laravel installer, using Sail, or any other way you prefer to create a new application:

You might have noticed that the Laravel installer now supports Git and GitHub integration assuming you have the minimum git version required, you should have a new repository and a first commit.

Versioning our demo project is an excellent way to visualize the stub changes we make along the way and see what kind of files Laravel publishes to the app.

Publishing Stubs

The first step in customizing stubs could be to add stubs you’d like to customize individually to the /stubs folder at the root of a Laravel project, or you can publish all of them with Artisan:

As you can see, we have quite a few stubs published in the app folder! I’ll leave it up to you if you want to version all of them, but you could either keep a copy of them or only keep the specific stubs you want to customize.

Custom Controller Stubs

Laravel 8.36 introduced the idea of a --type flag when making a controller, allowing you to write custom stub files for generating a controller:

After adding the custom stub class, you can generate a controller using this template:

Which would generate the following controller file:

While this flexibility level is neat, I believe most developers can fit within the bounds of the stubs provided by the framework. Using the new --type flag is a manual way of picking which controller template you want to generate:

Which would generate a file based on the stubs/controller.plain.stub file published by Laravel:

A Sane Approach

Suppose you wanted to prepend a copyright comment to every file generated in your Laravel application. In that case, you could consider versioning all available stubs, and as you upgrade, run the stub:publish command to get newly added stubs.

For typical use-cases, though, perhaps you might only version the stubs you need to customize. For example, let’s say that you don’t want any controllers to extend the base Controller class; you could version all the controller.* stubs with your customizations but remove all the other stubs.

What If Stubs Change Upstream?

Let’s say you version all the stubs from stub:publish, but you are concerned that as the Laravel framework receives updates to core stub files, your app will be out-of-date. If you want to version all stubs for some reason, you can always force an update of stubs.

Take this for example, let’s modify a stub and commit it to Git:

You’ve updated the test stub and committed the update to Git. Let’s say later Laravel publishes some updates to stubs and you want to verify if any have changed:

You have an easy way to see how your stubs have diverged from the Laravel codebase over time! Since the stubs are versioned you can simply undo changes the --force flag causes if you need to merge your changes with the latest stub changes.