Merge target config with common config
szimek opened this issue · 3 comments
I've got the following configuration:
ngconstant: {
options: {
space: ' '
},
development: [{
dest: '<%= yeoman.app %>/scripts/env-config.js',
wrap: '"use strict";\n\n <%= __ngModule %>',
name: 'envConfig',
constants: grunt.file.readJSON("config/development.json")
}],
staging: [{
dest: '<%= yeoman.app %>/scripts/env-config.js',
wrap: '"use strict";\n\n <%= __ngModule %>',
name: 'envConfig',
constants: grunt.file.readJSON("config/staging.json")
}],
production: [{
dest: '<%= yeoman.app %>/scripts/env-config.js',
wrap: '"use strict";\n\n <%= __ngModule %>',
name: 'envConfig',
constants: grunt.file.readJSON("config/production.json")
}]
}
The first 3 options are the same for all targets, however, moving them up to common config doesn't set them on target configs.
wrap
should work but the other options can not be set as global parameters. This can be related to #12.
@mlegenhausen There's also an other issue when using "multiple module option" - it breaks running grunt with --verbose
option. It's probably the same issue as iammerrick/grunt-parallel#11.
I'm not sure though how the configuration should look like to handle single and multiple modules together with the default task/target options. In theory in case of multiple modules there could be the default options for the task, the default options for the target and then options for specific module.
Maybe just skip single module option and do sth like this:
ngconstant: {
options: {
// task defaults
},
development: {
options: {
// target defaults
},
modules: [{
// module options
}]
}
}
No idea how other tasks handle similar configuration.
I think it is not intended to remove all redundant information from a configuration that can happen. Instead we should find a trade-off.
Currently I would think that dest
, name
and constants
can be redundant, cause it can be common to have several dest
paths for several environments. The name
doesn't fit for me in the options
and should be used a identifier for multi constants definition (currently I merge by index instead by name, maybe I add this feature) and the constants
are normally always different between different environments.
I like your idea with the modules
parameter.
We should continue the discussion in #12. It would be nice if you can give me an example how your configuration should look like.