Menü schliessen
Created: May 20th 2021
Last updated: June 18th 2021
Categories: IT Development,  Laravel
Author: Marcus Fleuti

Laravel: Directory Structure

Donation Section: Background
Monero Badge: QR-Code
Monero Badge: Logo Icon Donate with Monero Badge: Logo Text
82uymVXLkvVbB4c4JpTd1tYm1yj1cKPKR2wqmw3XF8YXKTmY7JrTriP4pVwp2EJYBnCFdXhLq4zfFA6ic7VAWCFX5wfQbCC

Root directory

App directory

The app directory contains all the core code of the application. Almost all classes in your application are going to be in this directory.

Bootstrap directory

The Bootstrap directory contains the app.php file which bootstraps the whole framework. This directory also has a cache directory which contains framework generated files for performance and optimization such as the route and service cache files. Normally you don't need to modify anything in this directory.

Config directory

This directory contains all configuration files. It is a great idea to read through those files and check all the available options.

Database directory

It contains all your database migrations, model factories and seeds.

Public directory

This is where the index.php file is stored. This file is the entry point for every request that's entering your application. It also configures autoloading. The directory also has assets like images, JavaScript and CSS.

Resources directory

The resources directory contains all views as well as all raw uncompiled assets such as CSS and JavaScript. This directory also includes all the language files.

Routes directory

The routes directory houses all of the route definition for your application. By default Laravel includes several route files:

  • web.php
  • api.php
  • console.php
  • channels.php

The web.php file contains routes which the RouteServiceProvider places in the web middleware group. This provides the session state, CSRF protection and cookie encryption. If the application isn't offering a stateless RESTful API then it's likely that all of the routes are going to be defined in the web.php file.

The api.php file contains routes that the RouteServiceProvider places in the API middleware group. These routes are thought to be stateless, so requests which are entering the application through these routes should be authenticated via tokens and will not have access to the session state.

The console.php file is where you can define all of your closure based console commands. Each closure is bound to a command instance, which allows you to simply interact with the command's I/O methods. This file does not define HTTP routes but it defines console based entry points.

The channels.php file is where you may register all the event broadcasting channels that are supported.

Storage Directory

The storage directory contains logs, compiled Blade templates, file based session, file caches and other files generated by the framework. This directory is seperated into app, framework and logs.
The app directory is used to store files, that are getting generated by the application.
The framework directory is used to store framework generated files and caches.
The logs directory contains your application's log files.

Tests directory

This directory contains all your automated tests. Example PHPUnit tests and feature tests are provided out of the box. Each class should be suffixed with Test.

Vendor directory

The vendor directory contains all your Composer dependencies.

App directory

The majority of the application is stored in the app directory. By default this directory is namespaced under App and is autoloaded by Composer using the PSR-4autoloading standard.

The app directory contains a variety of additional directories such as Console, Http and Providers. The Console and Http directories are providing an API into the core of the application. The HTTP protocol and CLI are both mechanisms to interact with your application, but don't actually contain application logic. The console directory contains all of your Artisan commands, while the Http directory houses your controllers, middleware and requests.

A variety of other directories are getting generated inside the App directory as you can use the make Artisan commands to generate classes.

Broadcasting directory

This directory contains all the broadcast channel classes for the application. The classes are generated using the make:channel command. The Broadcasting directory won't exist by default, but it'll be created for you when you create your first channel.

Console directory

The console directory contains all of the custom Artisan commands for the application. The commands can be generated using the make:command command. This directory also keeps the console kernel, which is where the custom commands are registered and the scheduled tasks are defined.

Events directory

This directory is not existing by default, but will be created for you by executing the event:generate and make:event Artisan commands. The Events directory keeps event classes. Events are used to alert other parts of the application that a given action has taken place.

Exceptions directory

The Exceptions directory contains the exception handler for the application and is also a great place to place any exceptions to be thrown by your application. If you want to customize how the exceptions are logged or rendered, you have to modify the Handler class in this directory.

Http directory

The Http directory contains your controllers, middleware and form requests. Almost all of the logic to handle requests will be placed in this directory.

Jobs directory

This directory won't exist by default but will be created if you execute the make:job Artisan command. The Jobs directory keeps the queueable jobs for the application. Jobs may be queued by your application or run synchronously withing the request lifecycle. Jobs which are running synchronously during the current request are sometimes referred as "commands", because they are an implementation of the command pattern.

Listeners directory

This directory won't exist by default but will be created if you execute the event:generate or make:listener Artisan commands. This directory contains the classes that handle your events. Event listeners receive an event instance and perform logic in response to the event that is being fired.

Mail directory

This directory won't exist by default, but will be created if you execute the make:mail Artisan command. The Mail directory contains all classes that are representing emails sent by the application. These mail objects allow you to use all of the logic of building an email in a single, simple class that my be sent with the Mail::send method.

Models directory

The Models directory contains all of your Eloquent model classes. The Eloquent ORM is included with Laravel provides a beautiful, simple ActiveRecord implementation for working with the database. Each table has a corresponding model which is used to interact with that table. Models allow you to query data in your table, as well as inserting new rows in the table.

Notifications directory

This directory won't exist by default, but will be created if you execute the make:notification Artisan command. The notifications directory contains all the "transactional" notifications that are sent by the application. Laravel's notification feature abstracts sending notifications over a variety of drivers like email, Slack, SMS or stored in database.

Policies directory

This directory won't exist by default, but is getting created if you execute the make:policy Artisan command. The Notification directory contains the authorization policy classes for the application. Policies are used to give rights to some users.

Providers directory

The Providers directory contains all of the service providers for your application. Service providers bootstrap your application by binding services in the service container, registering events or performing other tasks to prepare your application for incoming requests.

Rules directory

This directory does not exist by default, but you can create it with executing the make:rule Artisan command. The Rules directory contains the custom validation rule objects for your application. Rules are used to encapsulate complicated validation logic in a simple object.