http://www.phparch.com \ August 2019 \ 7Symfony 4: A New Way to Develop ApplicationsDirectory Structure
Symfony 4 comes with a reworked directory^15 structure.
The Symfony 3 directory structure^16 introduced a more stan-
dard Unix-like directory structure, with fewer sub-directories.
Symfony 4 keeps going in that direction. I think the new code
structure in Symfony 4 is much better organized (Figure 7);
it is more logical, and it gives us clearer guidelines on how to
use the framework. The layout is more standardized, which
is a good thing.
First, the bin folder is the same as before. The entire config-
uration is moved to the config folder but with a very different
layout. parameters.yml and parameters.yml.dist are gone. The
main entry point for the container is an empty services.yaml
used to define your services and parameters. Configuration
for bundles you install via Composer is stored as individual
files—one file per bundle, per environment. The same goes
for the routing configuration. That’s a soft requirement for
auto-configuration but allows for a better file organization.
One significant change is the introduction of a bundles.
php file where installed bundles are referenced. One file
per bundle and bundles.php are the two core concepts that
enable Symfony to manage your bundles and their configu-
rations automatically.
You can still write configuration using PHP, XML, or
YAML as before. YAML is the default for Symfony4. The only
difference is the usage of the standard .yaml extension instead
of the current .yml one.
public is equivalent to web folder in previous versions,
but it contains only index.php. All other files like .htaccess,
favicon.ico, apple-touch-icon.png are optional and if you
need one, you add it. Not all projects need those files. If you
want skeletons for those files, they exist of course.
var/ is very similar to Symfony 3, with some minor tweaks
in the best practices.
var/cache/ should now only be used to store long term
cached contents like compiled container files, compiled
translations, or Doctrine proxies. No temporary files.
Anything stored under var/cache should have a warmup class
able to generate the cache files so the console app can warm
the cache. These should be files that are never updated after
deployment to allow for read-only filesystems.
src/ is where your code goes. The Kernel class has moved
to src/, where it belongs since it is part of your application.
You can change it if you need to, but it does not belong in
the root folder. The content is very different from the one in
Symfony 2. First, it uses the MicroKernelTrait trait. Then, it
implements the logic to load the bundles from bundles.php
and to read the various bundle configuration files. This logic
works as of Symfony 3.3.
In Symfony 4, everything is optional. As you can see, we
are not using Twig (templates) at the moment, and in Figure
15 reworked directory: https://phpa.me/symfony4-directories
16 directory structure: https://phpa.me/symfony3-dir-issues
7, there is no folder for templates. In Symfony 4, by default,
templates are put in a first-level templates/ folder. The same
goes for tests; they moved to a top-level tests/ directory.
As we explained already, when using Composer to add a
new bundle, Symfony 4 leverages this new directory struc-
ture to automatically register the bundle in bundles.php, copy
some sensible configuration under config/, and much more.
And this is an awesome thing! You add things at the precise
moment you need them.Figure 7