[Proposal] Create a command to reset a recipe

[Pierstoval]

Current situation

As we already know it today, there is no upgrade point for Symfony applications.

With Standard Edition, we need to copy/paste code from the SE into our app when we want to "follow the SE upgrade path".

With Flex, it's gonna be the same in the case of the skeleton composer.json file, but worst part is for the recipes.

Upgrade example

Let's imagine a case that can easily occur in real life:

I'm using SF3.3 today with the good ol' Standard Edition. I'm upgrading to Flex in November when it releases. Fine, a few days of work to adapt it, it's a big app, but it seems ok, and I can deploy on prod.

A few days/weeks/months/years/whatever later, I need to upgrade my app to Symfony 4.

We all know the huge amount of changes in Symfony best practices since Symfony 3.0, maybe my app was using old practices that are highly deprecated, and in order to avoid having to spend hundreds of hours debugging my code etc., I'd like at least to upgrade my packages without them to throw deprecations in their own code because I'm using old config.

And I don't want to run composer update and make it fail everytime because a package is badly configured.

So I might need the "new" configuration for every package that is covered by a recipe.

Proposal

My idea is to create a command in the Flex plugin to do something like this:

$ composer flex:recipe:reset [--diff] [--overwrite] [packages...]

This command would download the full recipe of the package's currently installed version, and may, depending on the best / easily doable solutions:

• Maybe uninstall & reinstall recipe files. The advantage is that it would avoid having files that are no longer used by the new version of the recipe.
• Just reinstall the recipe without removing old files, but instead, overwrite all files of the recipe that have to be installed.
• Maybe compare files, it seems like a very hard challenge, but actually, apt is doing so when package config files are updated in your /etc folder (let's say, php.ini 😄)

Any of these options can be harmless for the end-user when using versionning, because any git diff in CLI allow seeing the changes, any visual Git diff application (like the PHPStorm's bundled one) can help debugging the upgrade changes and adapt them to our needs.
And as said before, this diff can also be handled directly in the command line, even though it's not the best option to me, but it has the advantage of being used programmatically by any CI or even by symfony.sh's bot for testing purposes.

Maybe other ideas about this might come, but with this first shot, what do you think?

Are the use cases relevant enough?

[Pierstoval]

Six supporters for this proposal, but nobody from the core team. Should I start working on it or can we forget this and close the issue?

[fabpot]

It's not easy :) Especially as the user might have changed files. I do have a prototype doing crazy diffs to try to do its best, but it's not finished yet.

[Pierstoval]

The diff tool is just to add more fanciness, that's why I propose a --overwrite (or --force or --force-write or whatever) option plus a Files already exist, overwrite? [y/N] prompt, to not overwrite anything by default.

And to make diffs, we could use already existing tools like diff, which is already installed in many *nix distributions as well as cygwin and mingw for windows (and WSL too), and if nothing is installed, show a slight warning No external diff tool available, install \diff` if you want to view a diff of the recipes reset`.

For the rest, I believe most devs will use Git and will be able to use their favourite diff tool (like said in the issue: phpstorm's built-in one, git's diff, vimdiff...) to check what Flex really did. After all, resetting recipes like this will certainly induce breaking changes for the app, and we can't make that big diffs manually. No need to reinvent the wheel, I think this is a case where devs will already know what they're doing.

[nicolas-grekas]

composer fix-recipes --force => ignore symfony.lock & overwrite existing files

[Pierstoval]

composer fix-recipes --force => ignore symfony.lock & overwrite existing files

Would be totally ok for me 👍