Five Things to Consider for a Fresh Laravel Project

Originally posted in my blog

Introduction

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!

Disclaimer

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 :)

1. Move your Eloquent models into a Models namespace

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 App\Requests.

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\Billing or Models\Customers depending on your problem domain.

2. Use an in-memory SQLite database for testing

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_CONNECTION and DB_DATABASE within the <php> block:

<php>
  <env name="DB_CONNECTION" value="sqlite"/>
  <env name="DB_DATABASE" value=":memory:"/>

  <!-- omitted for brevity... -->
</php>

3. Install Telescope for development

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.

4. Change the application name

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 Foo\Providers etc.

5. Change the frontend preset

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

Conclusion

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!

Do you have any questions? Feel free to contact me on Twitter @alchermd. Until next time!