Every web project will have assets.  Assets are static files that are delivered to the user’s browser by the web server, for example, images, stylesheets and javascript files.  Assets included in your project can be your own, e.g, your own javascript and CSS files, or third-party, like the main JQuery file that you have downloaded and included in your project.  If you use the symfony framework to develop your web application, you will need to make decisions as to where to store these assets.  Of course, assets eventually need to be somewhere in the ‘web’ folder in a symfony project (either physically or symbolically linked), for them to be of any use, since they need to be publicly accessible.  As we will see, in symfony we can organise and store our assets outside of the ‘web’ folder in source control, but when the application is deployed, we have to arrange so as to have these assets ‘dumped’/’installed’ in the web directory.

Basically, with symfony, the choice of where to place assets boils down to whether to place them in bundles or no.  According to bundle best practices (http://symfony.com/doc/current/bundles/best_practices.html), it is not recommended to embed third-party assets in a bundle.  But if your bundle provides a beautiful and interactive HTML form, you will want the related images, CSS and javascript to live inside your bundle, so that a user can download everything with the bundle.  On the other hand, assets specific to the application, and not reusable, will not form part of any bundle.  They might be stored somewhere in ‘app/resources’ or directly in ‘web’.

Storing assets in bundles and the assets:install command

There is a convention whereby bundle authors store any assets that come with their bundle inside the ‘Resources/public’ directory of the bundle.

The framework bundle comes with the native command assets:install.  What this does is that it makes the entire directory hierarchy found in the ‘Resources/public’ directory of each bundle registered with the application kernel, accessible publicly, by either hard copying to or creating symlinks into ‘web/bundles//’.  Thus if a bundle named SuperBlogBundle had the following asset structure: Resources/public/{css,js,images}, after executing assets:install these would be available via web/bundles/superblog/{css,js,images}.

This command allows to either hard copy the files or to generate symlinks.  Apparently (http://symfony.com/blog/new-in-symfony-2-6-smarter-assets-install-command) before symfony 2.6, on systems that did not support symlinks, an exception was thrown.  But now it silently falls back to hard copying if symlinking is not available.  We can also specify options whether to use absolute or relative symlinks.  The command also accepts a single argument: the target directory, which, if omitted, by default is ‘web’.

Note that the command scans the ‘Resources/public’ directory of bundles only; notably, the ‘app/Resources/public’ directory is not used (it is part of the application but not inside any bundle).

So if you are authoring a reusable, shareable bundle, you can use this approach with assets that come with your bundle.  In your HTML files/twig templates, you will then reference your assets from the ‘bundles/lowercase_bundlename/’ directory.

Storing assets in web folder directly

Assets that are not reusable will not be stored in bundles.  It is best to store these directly in the ‘web’ directory.  We could have, let’s say, separate folders for images, CSS and javascript directly inside ‘web’.