In this short article, we’re going to explore some things you might consider for your new Laravel project. A lot of new developers goes straight from
laravel new myproject to writing code without any thoughts or considerations, so here’s a list of things that could be of use after your first
git init. Let’s get started!
The following are just opinions and shouldn’t be taken as hard rules to follow. I suggest you try them out, see if it feels right, and decide from there. You think it just made things complicated? Revert the change and let it be :)
The default Laravel directory structure places most of your application logic within the
app directory, in which several Artisan commands will generate files within a predefined directory/namespace for you. As an example,
php artisan make:request SaveArticle will create a new file named
app/Requests/SaveArticle.php which is also namespaced for you under
But how about your application’s Models? The documentation regarding directory structure states that:
"”When getting started with Laravel, many developers are confused by the lack of a models directory. However, the lack of such a directory is intentional. We find the word ““models”” ambiguous since it means many different things to many different people. Some developers refer to an application’s ““model”” as the totality of all of its business logic, while others refer to ““models”” as classes that interact with a relational database… “”
That’s fair enough, I must say. But personally, after working on a bunch of Laravel projects, I see that Eloquent models start to clog up the root
app directory more often than not. So I suggest that from the start (with the default
User model), create and move your Eloquent models within a
Models directory. Down the road when you need more separation, you can easily add a
Models\Customers depending on your problem domain.
I personally feel like this should be the out-of-the-box configuration for Laravel. When you run your test suite, PHPUnit will honor the contents of your
phpunit.xml. One of the very first things that I change for a new Laravel project is to use an in-memory SQLite database instead of creating a traditional RDBMS like MySQL or PostgreSQL specifically for tests. This will make test execution faster, and if you stick with standard SQL commands, can be a huge benefit for running CI tests.
To do this, you need to edit your
phpunit.xml set the
DB_DATABASE within the
<php> <env name=""DB_CONNECTION"" value=""sqlite""/> <env name=""DB_DATABASE"" value="":memory:""/> <!-- omitted for brevity... --> </php>
After struggling a bit with setting up and production issues, I’ve finally settled in and accepted Laravel Telescope as a staple for my current and future projects. This little first-party tool gives your development experience a nice boost. It allows you to inspect requests, render sent mail, watch your queue live, and a whole lot more.
Just make sure to read the installation instructions carefully so you won’t yourself into weird issues down the line.
This is more of a consideration if you’re building a package that is meant to be reused, but you might want to change your application name so that the
app directory will be namespaced according to your preferred name, instead of just
App. An Artisan command is available that does this exact thing:
$ php artisan app:name Foo
This will namespace your
app directory, so that
App\Providers will be
A web application can be expected to do some extensive front-end work in its lifetime. Laravel gives us some excellent front-end tooling for free with Laravel Mix and the pre-generated VueJS structure that can be found within the
resources/js directory. But do you know that you can just as easily swap this preset with React or even remove the preset entirely? Just go ahead and
# Swaps from Vue to React $ php artisan preset react # ... or remove the scaffold and go vanilla! $ php artisan preset none
We covered some techniques that you might consider for your new Laravel project. Again, feel free to adapt, remove, or extend these ideas depending on the needs of your project. Remember to make smart decisions across the lifetime of your project!
Got any feedback or suggestions? Feel free to send me an email or a tweet.