Failure during install fails to update composer.json file

[nicolas-grekas]

steps to reproduce

composer create symfony/skeleton foo
cd foo
composer config minimum-stability dev
composer req api

buggy outcome 1/2

Script make cache-warmup returned with error code 2
!!  
!!    [Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]  
!!    You have requested a non-existent service "".                               

how do you quickly debug that btw? the error message is just useless...

buggy outcome 2/2

composer.json file doesn't contain anything about api-platform, despite the fact the package is installed and listed by composer show.
Do composer up and they are just removed, leaving Flex in an inconsistent state.

[fabpot]

Indeed, that's a known issue. The issue here is that if Composer scripts fail, composer reverts the changes done in composer.json. So, a composer up removes the package as it's not listed in composer.json. Not sure what we can do here . Any suggestions?

[fabpot]

We could make running the scripts non fatal.

[nicolas-grekas]

Can we hook after composer write the composer.json file?
If yes, can we store the exit status, make the scripts not fail from composer pov, then exit 1?

[nicolas-grekas]

Does composer have any issue already about it? Willing to solve it there? Ping @Seldaek

[chalasr]

1/2 is due to api-platform requiring some packages in dev versions, giving a mix of FWB 3.3 and console 3.4/4.0, leading to $container->get(false) because this check is not there in FWB 3.3. We need to either backport the check in FWB:3.3 or add a conflict rule for console>3.4 in FWB:3.3.

[stof]

@nicolas-grekas I don't know of any issue related to this. This would probably involve a new -ignore-script-failure in the require command of composer, to avoid rolling-back the change and the update in case a script fails (allowing you to fix the code and run the command again)

We need to either backport the check in FWB:3.3 or add a conflict rule for console>3.4 in FWB:3.3.

@chalasr having to to this is a sign of a BC break for the console.command.ids parameter in 3.4. We may need to change 3.4 to avoid this instead.

[chalasr]

@stof you're right, I'll look at it.

[weaverryan]

@Seldaek @naderman Could you guys help? Is there a way to make Composer not revert the composer.json file when a script fails? Or would that need to be added to Composer?

I keep hitting this bad behavior in Flex - it's a major ugly spot :/.

[stof]

We discussed this during the hackday, and they were OK for reverting the composer.json change only for the resolution and installation part, and not for post-update script failures. But @Seldaek said he has not time to work on it soon. So if we want a fix sooner, it is better to provide a PR rather than waiting for him to implement it.

[weaverryan]

I've just tried something: composer/composer#6842

Do you guys see any issues? If not, could you review/support it?

[weaverryan]

This should be fixed when Composer 1.5.3 is released: composer/composer#6842 (comment)

We don't print a message at the bottom, but the composer.json file is NOT reverted:

I think this is quite fine 👍

[Seldaek]

It looks quite horribly verbose though for a failure that is kinda expected and frequent.. Maybe that could be improved in flex or the cache clear command or both :)

[bitgandtter]

I think this is a responsibility of the bundle or package to improve the DX and provide a well integrated recipe, in this case DoctrineBundle should provide the version parameter so it avoids the connection and by that the env requirement and by consequence that issue is not presented.