Flex: [Question] Why are assets enabled by default?

[javiereguiluz]

If I create a Symfony app with Flex and then install the cli package to access to Symfony commands, I see the following:

$ ./bin/console

Symfony 3.3.0-DEV (kernel: src, env: dev, debug: true)

Usage:
  command [options] [arguments]

...

Available commands:
  about                   Displays information about the current project
  help                    Displays help for a command
  list                    Lists commands

 assets
  assets:install          Installs bundles web assets under a public web directory

 cache
  ...

Why is assets:install command enabled? I didn't expect to see it unless I enable/install assets support explicitly.

[fabpot]

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

[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.

[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?

[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 :)

[fabpot]

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

[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]

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.

[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]

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?

[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!