I'm explaining here what's the concept behind this pull request because it will be linked in my talk and also because it should be used for a future documentation.

The importers

The "importer" is just a name I gave to these sort of "front controllers".

// bundles/imports.php
foreach (glob(__DIR__.'/*.yml') as $file) {
    $loader->import($file);
}

These files should be used when our configuration files contain different roots.

Using these simple .php files some things can be prevented:

• instead of a huge list of imports, we can write just a - resource bundles/imports.php
• big configuration files
• a configuration containing mixed roots, each file under the directory containing the imports.php file can be called as we want, and the best solution should be the root of the bundle configuration we are writing

Overrides

The less our configuration files contain, the better it is! Sometimes there are different ways to write a configuration:

# example-1/config.yml
fos_user:
  registration:
    confirmation:
      enabled: false

# example-1/config_prod.yml
fos_user:
  registration:
    confirmation:
      enabled: true

This is the most simple case, here we don't want the confirmation email while we're developing, so it's required only in production.
Everything seems ok, but there's a wrong assertion behind: dev == test == * != prod.
In fact if we want to test the confirmation email, the configuration has to be duplicated and we don't know if the test has to depend from the development environment or the production environment (if we don't have a sender address in dev, what should be used?).

# example-2/config.yml
fos_user:
  registration:
    confirmation:
      from_email: # ...
      enabled: false

# example-2/config_prod.yml
imports:
- resource: config.yml

fos_user:
  registration:
    confirmation:
      enabled: true

This is the kind of configuration organization you can find in the symfony/symfony-standard and it's better than the first: if we don't want repeat our configuration (e.g. the from_email) we simply need to override it in the chosen environment.

# example-3/config.yml
fos_user:
  registration:
    confirmation:
      from_email: %confirmation_from_email%
      enabled: %confirmation_enabled%

By defining the confirmation_enabled parameter in our parameters.yml.dist, it can be based on the environment, so the test environment can be really independent from the prod and dev environments (and overridden if the confirmation_from_email isn't the same of dev).

Tip

If you're creating a bundle that requires a configuration, try to use parameters too, like the DoctrineCacheBundle does:

# common/doctrine_cache.yml
doctrine_cache:
  providers:
    foo:
      memcached:
        servers:
          memcached01.ss: 11211
    bar:
      memcached:
        servers:
          memcached01.ss: 11211
    test:
      memcached:
        servers:
          memcached01.ss: 11211

isn't the same of

# common/doctrine_cache.yml
doctrine_cache:
  providers:
    foo:
      type: memcached
    bar:
      type: memcached
    test:
      type: memcached

# parameters.yml
parameters:
  doctrine_cache.memcache.host: memcached01.ss

Naming Strategy

Naming strategies are different and depend on what should be identified.

If a class is used as a service then the identifier is the full namespace lowercase, with and underscore separating uppercase letters and a dot instead of the backslash, so for example VendorBundle\Package\LibraryController become vendor_bundle.package.library_controller

If something must refer to a configuration, try to use the full configuration tree, for example:

doctrine_cache:
  providers:
    doctrine.orm.metadata_cache_driver:
      type: apc

doctrine:
  orm:
    metadata_cache_driver:
      id: doctrine_cache.providers.doctrine.orm.metadata_cache_driver
      type: service

Tip: Always look the bundle configuration, the last half of this example can be prevented if you know the existence of the service doctrine.orm.default_metadata_cache! ;)