Migrating ProductBundle\DependencyInjection

[hackzilla]

On the page https://symfony.com/doc/current/setup/flex.html

There should be mention of how to migrate existing DependencyInjection component of a bundle.

The closest link I've found are https://symfony.com/doc/current/bundles/extension.html#cookbook-bundles-extension-config-class and https://symfony.com/doc/current/bundles/configuration.html
but they have very few bits on Flex specific setups.

[hackzilla]

I have found this StackOverflow answer, about reimplementing an AppBundle, but that felt wrong.
https://stackoverflow.com/a/48875690/157656

[hackzilla]

The only way I've found that works, is putting the values in services.yml in parameters.

Or I could make a separate bundle to handle config.

[javiereguiluz]

Fully explaining how to do this migration would be too complex ... but I agree we could mention this explicitly in the upgrade guide ... so I've opened #10984. Thanks.

[hackzilla]

It's great you've added those bits in #10984, but it doesn't fix this issue.

Flex was about bringing simplicity.
Before, we had an AppBundle, but we could define our config structure.
Before, we were told we were creating too many bundles.

Now we have to create a bundle specifically to handle config?

Fully explaining how to do this migration would be too complex

That worries me. Things should be getting simpler.

[javiereguiluz]

In my opinion, the complication comes from this --> instead of doing the following, which is trivial, works perfectly, and requires zero effort:

# config/services.yaml
parameters:
    app.some_param: '...'
    app.another_param: '...'

Some people insist in creating something like this, which works the same, but it's much more complicated, requires lot of work and maintenance, etc:

# config/packages/app.yaml
app:
    some_param: '...'
    another_param: '...'

This also matches the recommended way of working with config according to Symfony Best Practices: https://symfony.com/doc/current/best_practices/configuration.html

[hackzilla]

@javiereguiluz that makes a lot more sense.
It's a shame to lose validation, but I guess you'd struggle prevalidating env values.

[javiereguiluz]

Fixed by #10984.