Closed steven-pribilinskiy closed 7 years ago
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.
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:
maba:webpack:*
commands to e.g. assets:*
that are defined in CompileCommand
and DevServerCommand
maba:webpack:setup
that is completely useless here, as we already have a custom webpack.config
description
and help
of commandsI'll also work on a specific assets:menu
command that will use the mentioned above terminal-menu
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
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'