Configuration files organization when using the full-stack framework

[fabpot]

The default way to store configuration files in the Symfony standard edition was choosen for its simplicity: one file per environment. But that's just the default way.

When your configuration files grows, you might want to adopt a slightly different strategy where you create for instance one configuration file per bundle. But as it's definitely not needed by default (default configuration is quite short), I think that a cookbook about different ways to store your configuration might help people think about the best way for their project.

See symfony/symfony-standard#599 for the discussion that triggered this ticket.

[wouterj]

This should be documented in a new cookbook article in the "Configuration" subject (we might want to split that subject into 2 subjects, but that's not related to this issue)

[lavoiesl]

Following the same idea, I came up with a full implementation of a DirectoryLoader and with documented examples on how to separate everything.

See https://github.com/wemakecustom/DirectoryLoaderBundle and https://github.com/wemakecustom/symfony-kickstart/tree/master/dist for the final tree:

app
├── AppKernel.php
└── config
    ├── config
    │   ├── common
    │   │   ├── assetic.yml
    │   │   ├── doctrine.yml
    │   │   ├── framework.yml
    │   │   ├── security.yml
    │   │   ├── swiftmailer.yml
    │   │   └── twig.yml
    │   ├── dev
    │   │   ├── assetic.yml
    │   │   ├── framework.yml
    │   │   ├── monolog.yml
    │   │   ├── swiftmailer.yml
    │   │   └── web_profiler.yml
    │   ├── prod
    │   │   ├── assetic.yml
    │   │   ├── doctrine.yml
    │   │   └── monolog.yml
    │   └── test
    │       ├── framework.yml
    │       ├── swiftmailer.yml
    │       └── web_profiler.yml
    ├── config.yml
    ├── parameters
    │   ├── common
    │   │   ├── core.yml
    │   │   ├── i18n.yml
    │   ├── dist
    │   │   ├── mailer.yml
    │   │   └── security.yml
    │   └── local
    └── routing
        ├── common
        │   └── fos.yml
        └── dev
            ├── common.yml
            ├── configurator.yml
            └── profiler.yml

This also uses directories for parameters with dist/local/common folders, replacing Incenteev’s parameter builder.

If someone likes the idea, I am willing to give a hand with the documentation, improving #3885 or starting another. I would also appreciate some feedback or comments.

[wouterj]

If people like the bundle, we can add a little tip box with a link to the bundle in that article after #3885 is merged.

[xabbuh]

I like the idea. But I don't think that this should be put in a bundle. For me, it should be a standalone library which could also be used if you used the components without the full-stack framework.

[cordoval]

@xabbuh i think Christian is very right here, this should be a library, and try that one to be well decoupled. I think this can rock 👍

[stof]

@xabbuh @cordoval see symfony/symfony#11045

[lavoiesl]

Both of the loaders are usable as is, but you still need the bundle to register them in Symfony itself.

Do you suggest I create a project for directoryloader-di, directoryloader-routing and directory-bundle ?

[wouterj]

Do you suggest I create a project for directoryloader-di, directoryloader-routing and directory-bundle ?

@xabbuh suggested that you should create a DirectoryLoader package with the loaders and a DirectoryLoaderBundle for their integration into Symfony. However, I don't think that is needed: It's a simple bundle and if you want the loaders, just require the bundle!

[lavoiesl]

Yes, that was my idea as well. I will configure the composer.json to be permissive, without requiring symfony-framework.

[lavoiesl]

I also added proper documentation: https://github.com/wemakecustom/DirectoryLoaderBundle#usage-without-symfony-framework

[xabbuh]

Well, Id rather prefer this to be separated into a library and a bundle. But I don't have too strong feelings with that. But, as @stof pointed out, your loader may be useful for Symfony itself. So, I suggest that you prepare a pull request for this on the Symfony repository.

[lavoiesl]

See @fabpot 's comment saying explicitly he doesn't want it: https://github.com/symfony/symfony-standard/issues/599#issuecomment-37621837