Handling application configuration

Question

Handling application configuration

mtymek opened this issue 10 years ago · 2 comments

While this module allows easy overrides to system configuration (this is where enabled modules are listed), it doesn't help with overriding application config (this is where modules are configured).

Why this is useful? For example, app developer can set variables useful for debugging:

return [
    'view_manager' => [
        'display_exceptions' => true,
    ]
];

This approach is better than having untracked .local.php files, as potential contributors don't need to put any effort on setting up debug environment, they can focus on contributing. Of course above example is pretty trivial, but as your project grows, you will have more differences between dev and prod environments*.

I'd like to address this problem by sending appropriate PR. I can see three possible solutions to this problem. Please share your thughts about which is best.

Separate directory for dev-only config files (my favorite). It is enabled in dev system config:

'module_listener_options' => [
    // An array of paths from which to glob configuration files after
    // modules are loaded. These effectively override configuration
    // provided by modules themselves. Paths may use GLOB_BRACE notation.
    'config_glob_paths' => [
        'config/{autoload,autoload-dev}/{,*.}{global,local}.php',
    ],
]

Using this approach dev config files are not mixed up with production. I implemented it in my "alternative" skeleton application - see here.

Different globbing for for dev mode. Enabled by adding following lines to dev system config:
```
'module_listener_options' => array(
'config_glob_paths' => array('config/autoload/{,*.}{global,local}-development.php')
)
```
With such approach, you can define one or more files that will included in dev configuration only: global-development.php, zf-tool.global-development.php. This approach is enabled (but not used) on ZF modules website - click.
Finally, a proposal from Matthew - application config override should be enabled in a same way as system config. It means that we'll have additional file in config/autoload directory, named config-dev.local.php.dist. When development mode is enabled, it will be simply copied into config-dev.local.php.

I like first approach, because it cleanly separates dev and prod config files. Dev may want to have a few of those - one to enable error reporting, second to configure developer toolbar, another one to add extra logging. "Approach 2" means that dev files are mixed up with default config, while "3" forces you to have everything in single file.

Let me know which approach is the best, so that I can send appropriate PR!

* yes, I know prod and dev configs should be as similar as possible. But often you'll really need extra configuration that is not trivial, like enabling Dev toolbar.

Answer 1 · 2014-08-14T08:58:53.000Z

ping @weierophinney @ezimuel

Answer 2 · 2014-08-14T22:08:42.000Z

For a variety of reasons, I prefer (3), and not just because I proposed it to you, but because it better fits in with the design of zf-development-mode. The idea with this module is to selectively enable/disable configuration, essentially, and to make it difficult to accidentally keep development artifacts enabled or to commit them to your repository. By using a dist file, we can easily remove the file it copies to; by naming that file using an existing glob pattern, we do not need to make further changes to existing applications other than dropping in the dist file.