Five Things to Consider for a Fresh Laravel Project
Tags: laravel, php
Published: 2019-03-02 04:19:20

---
title: Five Things to Consider for a Fresh Laravel Project
published: true
description: Since listicles are all the rage...
tags: laravel, php
canonical_url: https://johnalcher.me/articles/5-things-to-consider-fresh-laravel-project
cover_image: https://images.pexels.com/photos/459301/pexels-photo-459301.jpeg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940
---

<small>Originally posted in my <a href="https://johnalcher.me/articles/5-things-to-consider-fresh-laravel-project">blog</a></small>

---

## Introduction

In this short article, we're going to explore some things you _might_ consider for your new [Laravel](https://laravel.com) 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](https://laravel.com/docs/5.7/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](https://laravel.com/docs/5.7/structure#introduction) 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](https://laravel.com/docs/5.7/testing) suite, [PHPUnit](https://phpunit.de/) 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](https://en.wikipedia.org/wiki/Continuous_integration) tests.

To do this, you need to edit your `phpunit.xml` set the `DB_CONNECTION` and `DB_DATABASE` within the `<php>` block:

```xml
<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](https://laravel.com/docs/5.7/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](https://laravel.com/docs/5.7/telescope#installation) 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:

```bash
$ 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](https://laravel.com/docs/5.7/mix) and the pre-generated [VueJS](https://vuejs.org/) 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](https://reactjs.org/) 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](https://twitter.com/alchermd). Until next time!