flex: composer update: Undefined index: splits

Some people might need to wipe out their local flex dir before being able to update.

rm -rf vendor/symfony/flex && composer update symfony/flex

Can I ask why you thought it was acceptable to just break the old endpoint without clearly announcing a migration date? The blog posts I’ve read (and indeed read at the end of last year) just state an aspiration to move over at some point in the future.

We have not decided yet when we will shut down the current Flex server, but please upgrade at your earlier convenience to help us move forward faster.

All my CI jobs started failing today due to this, further exacerbated by the upgrade process being painful for those of us who’ve updated to PHP 8.1 in the meantime (not supported by laminas/laminas-code).

Is there a newsletter or some kind of channel where we can subscribe to for such critical / breaking updates? Please let me know.

Yes, vague warnings were posted on the blog and social media. Without any sort of “sunset date”, deprecation timeline or actionable plan that communicated when the change needed to be made.

Come on, you absolutely can do better than that. All the Symfony core releases have a proper release lifecycle with documented, well-communicated EOL dates. When functionality is deprecated, the version number where it is deprecated and the version number for its scheduled removed is explicitly documented in your blog posts too.

“earliest convenience” and “we have not decided yet when we will shut down the current Flex server” != “ASAP” in my mind, at all.

by just updating (running the mentioned command) you should be good

As I mentioned, it’s not quite that simple, I had to pin "laminas/laminas-code": "4.5.1" to get the updated Flex to install.

composer update symfony/flex --no-plugins --no-scripts

There is your problem, you’ve pinned the version to "symfony/flex": "1.9.*", try changing it to at least "symfony/flex": "^1.9.0" (added the ^ in front of the version). And run the mentioned command again.

We’ve been displaying error messages for the last couple of months whenever you run composer update. Unfortunately, returning 404 would not help as Composer would just ignore the recipes and you would not have anything useful. We’ve also made the server really slow at the same time (the 10 seconds delay) to try to get more feedback. As nobody complained, we thought that the traffic was mainly about bots and misconfigured CIs. I have also posted tweets over and over again to alert people. Unfortunately, there is nothing more I would have done (at least, we didn’t find anything else we could do).

I think the issue can be closed or limited to maintainers only. It is clear why it happened and what to do in order to fix it.

To help with searchability, some affected users may see this error instead:

[ErrorException] Undefined index: manifests

Some people might need to wipe out their local flex dir before being able to update. rm -rf vendor/symfony/flex && composer update symfony/flex

And that was the last missing piece of the puzzle on my side… removing vendors.

On my prod deploy i do a fresh install, It seems that the problem only happens on composer install, not update

@amine-betari I see that your folder is named ezplatform. Please look at the comment of @webhdx: https://github.com/symfony/flex/issues/890#issuecomment-1088527388 (Ibexa DXP is the new name of ezplatform)

composer update symfony/flex --no-plugins --no-scripts

There is your problem, you’ve pinned the version to "symfony/flex": "1.9.*", try changing it to at least "symfony/flex": "^1.9.0" (added the ^ in front of the version). And run the mentioned command again.

Thank you this helped

@fabpot , a version of flex that was functioning perfectly yesterday doesn’t work anymore today, without a single change at all. I don’t know, maybe this is not a breaking change, just a “it was working before but not anymore” change.

So, Symfony maintainers achieved the unprecedented feat of introducing a breaking change outside of a new release.

Their previous top achievement was when they introduced a breaking change in a patch release, but the sky is the limit.

Congratulations guys.

Apart from all the announcements and warnings that have been put in place, please note that 6 months have passed since the release of Symfony Flex 1.17. It is always a good idea to update your tooling more often than once a year (and as it’s not production code, it’s much more safe to do so).

Thanks for all the extra information - I’ve included some specialized troubleshooting info in the main description 😃

Ah ok, seems like there’s an issue for it already 😃 https://github.com/bolt/core/pull/3160

@stof that will indeed solve the error message issue, but it makes silently install 5.x symfony/* deps for a 4.4 symfony project, which is even worse. We ended up setting those packages one-by-one with 4.4.* in the required block of the composer.json to mitigate the problem. That’s what the extra.symfony.require - 4.4.* solved before, until the version.json was working, if I get it right.

I’m not saying it’s a bad thing, this situation will make us upgrade those remaining projects finally 😃

@K4T You might have a global installation of flex. Try running composer global update symfony/flex --no-plugins --no-scripts