Environment-specific or conditional webpack arguments

[steven-pribilinskiy]

As you probably know, the Symfony container supports an expression language. See also the expression syntax.

We would like to have similar in maba_webpack.bin.webpack.arguments Examples:

• @=environment == 'dev' ? '--debug --output-pathinfo'
• @=parameter('webpack_verbose') ? '--display-modules'
• @=parameter('webpack_logLevel') >= 1 ? '--display-modules'
• @=parameter('webpack_logLevel') >= 2 ? '--display-reasons --display-chunks --display-error-details'

[mariusbalcytis]

Wouldn't it be more clearer if you would parametrize your config.yml? As I see this, it would only be used for additional layer of abstraction (parameters to define another parameters). It would not be able to take any services, make calls to them etc. as these values are used as parameters currently. Unless it would be refactored to be calculated in run-time, as caching is not that important in this case.

Example config.yml:

maba_webpack:
    bin:
        webpack:
            arguments: %webpack_arguments%

parameters.yml.dist:

webpack_arguments: ['--hot', '--history-api-fallback', '--inline']

Each programmer would be able to add or remove any arguments as needed.

If environment changes how this should work (first example), you can just override some values inside config_dev.yml file.

[steven-pribilinskiy]

The idea behind having abstract params, e.g. webpack_verbose_log or webpack_log_level is to avoid reading webpack docs. Most of devs here don't want/need to learn possible command-line options of webpack. We use webpack about 2 years to build specific frontend single page apps without the help of a symfony bundle. Similarly to your suggestion in README, to use Plain simple webpack commands. But not in the way you may think. No one of the devs have insights in webpack, I've created a wrapper around webpack.config.js that shows a menu with terminal-menu and generates a config based on selected options. Here's a screenshot:

They even don't have to know what module bundler is used, it can be grunt, gulp, broccoli, whatever.

It's ok when you are alone developing your stuff, you know every bit of webpack and an array of plugins, you've watched tons of screencasts and read a book. But it's not ok when you're working in a company where every dev have it's own duties, expert in it's own field.

All backend devs here know perfectly Symfony and certainly they use app/console on a daily basis and occassionally change parameters.ini.

I am a frontend/fullstack dev and still in the process of learning Symfony conventions. It's not related to the issue, but maybe you can help with following tasks:

• rename maba:webpack:* commands to e.g. assets:* that are defined in CompileCommand and DevServerCommand
• remove maba:webpack:setup that is completely useless here, as we already have a custom webpack.config
• change description and help of commands

I'll also work on a specific assets:menu command that will use the mentioned above terminal-menu

[steven-pribilinskiy]

So, I've created the Assets*Command classes that have their own help and they execute a maba:* command through

$mabaInput = new ArrayInput([]);
$this->getApplication()->get('maba:webpack:compile')->run($mabaInput, $output);

remains to solve the problem with hiding the maba:* commands

Symfony have a native way to do this http://symfony.com/doc/current/console/hide_commands.html

The problem is that the ->setHidden(true) method should be applied in the vendor bundle's Command itself and probably it's a bit overhead to write some MabaWebpackCompilerPass to catch and modify the command. Another problem with setHidden is that it was added in Symfony v3.2 and we are currently on v2.8