Simplify configuration registration

[theofidry]

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC?	yes
Symfony version	master

I guess it's not everyone, but I personally use a lot of configuration files. I like to split them when it makes sense and avoid having config files that are too big. On my last 3 good sized projects (not all from me actually) the average was ~50 files.

I personally find very cumbersome to have to manually include them via config*.yml files, so I've done a small locator which register my config files automatically. It works as follow:

• scan the config dir to get all the files there
• filter files: some should not be included at all, e.g. routing and parameters.dist and other are environment specific
• load each of those files

So you basically have the following:

app/config/
    parameters.yml
    parameters.yml.dist  # ignored (like any `*.dist`)
    routing.yml          # ignored
    security.yml         # included for any environment
    security_prod.yml    # included only for the env `prod`
    framework.yml
    framework_prod.yml
    ...
    services/
        foo.yml
        foo_dev.yml
        foo_prod.yml

I would like to suggest to have that feature directly in the core (I can work on it), WDYT?

/cc DX master @weaverryan

[javiereguiluz]

In 2.8 we introduced a feature to load recursively all config files in directories. Would that help you?

    # Before Symfony 2.8
    imports:
        - { resource: acme/parameters.yml }
        - { resource: acme/security.yml }
        - { resource: acme/services.yml }

    # In Symfony 2.8
    imports:
        - { resource: acme/ }

See http://symfony.com/blog/new-in-symfony-2-8-dx-improvements#recursive-directory-loading-for-configuration-and-routing

[theofidry]

@javiereguiluz interesting feature I didn't know about it! But nope, there is two issues:

• You would need to recursively include config itself, I've just putted security.yml and framework.yml but I have a lot more at the root
• Files need to be included only for the right environment if they follow the _<envname>.yml pattern

[javiereguiluz]

You would need to recursively include config itself, I've just putted security.yml and framework.yml but I have a lot more at the root

Move the files to load automatically to a dedicated folder inside app/config/ ?

Files need to be included only for the right environment if they follow the _.yml pattern

Change your strategy and use <envname>/filename.yml instead of filename_<envname>.yml ?

[theofidry]

@javiereguiluz it's doable, but I'm not really fond of it, it requires too much tweaking with conventions I'm not happy with where I would like it to "just works". If you have:

config/
  infrastructure/
    doctrine/
      repositories.yml
  prod/
    infrastructure/
      doctrine/
        repositories.yml

This looks really annoying to me, I want repositories.yml and repositories_prod.yml next to each other.

But I understand it may be too opinionated to be integrated in the core. I'm just making the suggestion and see what people think of it.

[javiereguiluz]

@theofidry I totally understand you. It's doable ... but annoying. Let's wait for more opinions!

[sstok]

What if we add Glob support for the directory loader? What if we add a Glob file loader for directory loading?

- { resource: "acme/{framework,security}_%kernel.environment%.yml" }
- { resource: "acme/**_%kernel.environment%.yml" }

You can detect if it's a Glob because there are no filenames with {} (actually still possible as filename? I used this back in 2001 ) or *

[linaori]

You could make a convention that if the file name (minus .yml) matches the extension name, it would be loaded as such. Additional check: only actually load it if the first key in yaml also matches.

[theofidry]

@iltar not sure to have understood what you mean, could you elaborate?

[linaori]

• framework.yml loads the extension named framework
• iltar_http.yml loads the extension named iltar_http
• etc.

Requirement: The first key of the file has to match the extension name, so that same as it is now, but just a fail safe for autodetection.

[theofidry]

ah yeah that's what I do but not all my files requires an extension (if the default suffice, or if there is no extension, just services – yeah I have extension and service in the same file) and that requires to parse the file content before loading them, which is far from ideal as well.

[linaori]

Load the content, parse the yaml, then merge the arrays or skip it if it failed

[theofidry]

Hm actually when I decide if a file is loaded or not, I just choose the appropriate name, having the content matching is just a convention but it's not what I'm basing the loading on. For example if I want to add a file base_parameters.yml I want it to be loaded, not because of it's content (it could be empty), but just because it's name is not specific to an environment (hence included for any).