Configuration BC break in 0.11.12

[enumag]

Q	A
Bug report?	no
Feature request?	no
BC Break report?	yes
RFC?	no
Version/Branch	0.11.12

overblog_graphql:
    definitions:
        auto_compile: true

In YamlFileLoader.php line 666:
There is no extension able to load the configuration for "overblog_graphql"

If this is intentional then the docs are outdated.

[enumag]

Oh sorry it seems symfony/flex somehow deleted the bundle from bundles.php. No idea why.

[calvera]

flex deleted bundle config as well :(

[mcg-web]

This is maybe due to the merge of the generator lib in the bundle 🤔. I'll give this a try.

[ivoba]

This might be related:
when i want to upgrade from v0.11.11 to v0.11.12 composer says:

• Uninstalling overblog/graphql-bundle (v0.11.11)
• Updating webonyx/graphql-php (v0.12.6) to webonyx/graphql-php (v0.13.1)
• Updating overblog/graphql-php-generator (v0.7.5) to overblog/graphql-bundle (v0.11.12)

Which seems a bit weird: why updating overblog/graphql-php-generator to overblog/graphql-bundle ?

Also as the others stated flex deleted bundle config.

[mcg-web]

why updating overblog/graphql-php-generator to overblog/graphql-bundle ?

this change has been made for webonyx/graphql-php 0.13 support didn't know that flex would react like that. Anyway, that would be the same case when upgrading to 0.12 after the release.
This seem to be flex normal behavior.

With git you should be able to reverse your config changes.

[akomm]

@mcg-web Only reverting configuration is not clean enough, as the bundle/recipe is removed from symfony.lock.

• Make sure your config is committed (not staging changes)
• Update to 0.12-dev (or ^0.11) (flex will unconfigure)
• Remove vendor
• Run composer install. It makes flex to rediscover the recipe and write it into symfony.lock
• Revert your config now

@mcg-web any way to make the "ill" 0.11 to exclude from being installed via ^0.11 in projects which have the non-ill one currently in composer.lock, so when composer update is used it does not break?

For example with the rust's cargo system you can blacklist (but not remove) a version, which allows projects with locked version to install it, but new projects not receive the version.

I know I could now personally change version constraint to exclude the patch, but for other people its kind of a trap.