Why are assets in app/Resources/ ?

[wouterj]

This seems a bit strange to me. All assets are already ready compiled and ready to be used. Why not placing them in the web/ directory directly? (seems duplication for nothing)

Also, IIRC assets:install doesn't search through the app/Resources/assets directory.

[javiereguiluz]

You can find the answer in the Best Practices chapter about web assets:

Keep in mind that web/ is a public directory and that anything stored here will be publicly
accessible. For that reason, you should put your compiled web assets here, but not their
source files (e.g. SASS files).
http://symfony.com/doc/current/best_practices/web-assets.html

In an ideal world, we would only provide the source assets in app/Resources/. Sadly, to avoid any hassle to Symfony newcomers, we comment the Assetic code in the templates and provide the compiled CSS and JS files so they don't have to do it. This means that everything works in the application without having to do anything.

[stof]

@javiereguiluz why not using Assetic ? The dev env can use the controller, which does not require dumping assets before seeing the site. If you use only filters written in PHP, it does not require extra setup (well, it is not the case currently though)

[javiereguiluz]

These are our reasons for not using any tool to compile assets (neither Assetic nor JS stuff):

• We want users to browse the application both in dev and prod. It would be very strange to see the page perfectly in dev and without styles in prod.
• We use Sass for most of the styles. Even if PHP filters exist for compiling Sass (I use them in some applications) we prefer to use the real sass binary compiler to ensure 100% compatibility and 0 problems.
• Using Assetic slows down the application.
• Using Assetic takes some time because it requires learning some things in case things go wrong (as they usually go at first). We prefer that users see commented Assetic stuff in the templates and then they investigate that on themselves if they are curious about that.

In any case, please consider that the Symfony Demo is a very special application. We want to provide a full featured and perfectly working Symfony application in 10 seconds without asking any question, providing any option or requiring to execute any command. Thanks for understanding it!

[javiereguiluz]

Closing it as "resolved". Please reopen it if you consider that we need to keep discussing about this. Thanks.

[wouterj]

If anything, it is closed as "unresolved". I was almost sure I had commented on this issue, but turns out I didn't (btw, closing 4 days after last response is a pretty quick close timeline imo).

I can see why you don't use Assetic (I wouldn't actually recommend the usage of Assetic). However, why showing Assetic in this demo application at all? It isn't about showing all Symfony features, is it?

Why I don't think this is the correct to put the compiled source files in app/:

• assets:install doesn't install assets from app/Resources/assets/;
• it is against the standard convention of Resources/public/;
• it means duplicating files in app/Resources/ and web/ for no obvious reason;
• I think we should recommend to put public application files in web/ directly. There is no reason why one would want these to exist in the app/ dir (the current best practice already indirectly suggest something like this).

Btw, if a collaborator closed an issue/pull requests, only collaborators and owners can reopen it.

[javiereguiluz]

Sorry for having closed it so early. I want this repository to be very fast answering to problems/bugs and merging things ... and sometimes I'm too anxious.

• assets:install doesn't install assets from app/Resources/assets/;

Right!

• it is against the standard convention of Resources/public/;

That only applies to third-party bundles. Application assets should be in app/ or web/

• it means duplicating files in app/Resources/ and web/ for no obvious reason;

Yes, but only for some assets. In app/ we store the sources and in web/ the compiled assets. It's true that some things are duplicated (e.g. fonts)

• I think we should recommend to put public application files in web/ directly. There is no reason why one would want these to exist in the app/ dir (the current best practice already indirectly suggest something like this).

Maybe. I don't really know. As I understand current Best Practices, the "source assets" should be stored in app/. But we can discuss in symfony-docs repo to change the best practice and put all application web assets in web/.

[weaverryan]

Hi guys!

I don't think this is right yet either. These are the options I see:

A) Don't use SASS and just put things in web/. Probably a good short-term at least
B) Use SASS, but with a proper build system (e.g. gulp). This comes with its own baggage.
C) Use SASS with Assetic, but put things in the web directory. This is necessary because Assetic isn't robust enough to really handle things in app/Resources/assets. Because, for example, nothing is copying the fonts directory into web - we're doing it manually. That's just not very realistic.

I wasn't happy when I tried C locally. For one, I tried moving the compiled CSS into web/css/compiled to avoid mixing them with more source web/css files, but then you need the cssrewrite filter, and that wasn't playing nicely.

Thanks!

[stof]

@javiereguiluz I agree with @weaverryan here. If you don't want to use Assetic or gulp in the demo, don't use Sass at all and consider the CSS file in web/ as being the source. Otherwise, it will be confusing for users: should they edit the source sass file (which is totally ignored by the demo app) or the CSS file (which will then become out of sync with the Sass file, making the "source" Sass file useless)

[xabbuh]

For what it's worth: I agree with @weaverryan and @stof here.