[Question] Why are assets enabled by default?

[symfony]

[Question] Why are assets enabled by default?

[javiereguiluz]

You are right. But Symfony Flex no longer makes assumptions about the app you develop (that's why we don't include a "Welcome Page" or the server:* commands). So why should we include a utility to manage web assets? It's not needed when developing APIs, web servers, console apps, etc.

[umulmrum]

My 2 cents: Please do not increase the project setup cost and the learning curve height by introducing a requirement for external tools (especially node.js-based setups). Basic asset handling is great and there's nothing against replacing it in a project at will.

[ro0NL]

Perhaps considerable.. should SF offer this (frontend) solution at all? Looking at most of our projects today.. we dont really use/need it anymore since we moved to webpack and frontend specific commands/tasks (think gulp).

For the same reason deprecating templating, classloader and such. We have better tools :)

[Pierstoval]

@fabpot with such tools you don't have bundles that expose public assets. Everything is private and compiled by tools and task runners and dumped into the web dir, most of the time in a place which is covered by a .gitignore instruction to avoid versioning compiled files.

It's like if you have src/AppBundle/Resources/less/main.less and you compile it and dump it to web/css/main.css. Nothing public from the bundle is exposed.

That's what I do for my projects, even for images, I'm using only Gulp with this Gulpfile which uses a simple configuration array and already has all needed preconfigured tasks for most cases, and I even use the copy/paste command to get data from my node_modules and put them into a specific web directory. This keeps a total control over web assets that can be compiled as we want.

I don't know about webpack, but it is basically the same thing: you specify your sources and dump the modules in the web directory, so the sources are never public, and anything which should be "source" is always dumped into the web directory to ensure a "production-ready" assets management

[ro0NL]

Agee we can keep the current tooling available for basic asset handling, probably a lot of projects/bundles are using it. But @javiereguiluz has a point we should be able to decouple from it.

A way to do it is to further strip down the framework bundle into smaller bundles, i.e. AssetsBundle, FormBundle, etc. That would be a lot more flex ible right?

[fabpot]

assets:install has nothing to do with the asset components. It's to install bundle assets under web/

[fabpot]

@javiereguiluz That's correct. This command could be moved from FrameworkBundle to elsewhere... but where? I didn't find a good place, that's why I kept it here. What we could do is to only enable it when there is at least one bundle with assets, but not sure if this could be practical or even desirable. WDYT?

[fabpot]

@ro0NL How do you let bundles expose some public assets then?

[ro0NL]

We dont :) well.. our gulp task just scrapes bundles, something like

glob.sync('@(vendor|src)/**/*@(B|b)undle/Resources/public/assets/gulp.config.js')

But you really can do any setup you want. The current assets:install is more or less an opinionated setup, and can also be achieved writing a gulp task.

I'm also thinking to move assets+templates from bundles to the app layer. Without assets:install there's no default strategy available for opensource bundles to reference owned assets in owned templates. But that's exactly one of my goals.. fully separate the view layer. And avoid depending on "global" templates and such...

For webpack, we parse the generated stats.json that allows us to implement something like

{{ webpack_asset('path/to/assets/in/web', 'filename', 'ext'[, 'sf_asset_package_name']) }}

path/to/assets/in/web is basically a build directory, where dist files are written to.

[Koc]

Same question for routing configuration. For cli-only application routing not needed

[fabpot]

@Koc the skeleton and the recipes are web-oriented. If you want to create a CLI tool, there is no need for anything. A regular composer req symfony/console is enough.

[Koc]

we need doctrine infrstructure and httpplug

[javiereguiluz]

Closing because this is not simple to fix (where should we move this into?) but it could be fixed in the future as explained by @ro0NL if Symfony code continues splitting the old FrameworkBundle into smaller pieces. Thanks!