Unpack symfony/symfony

Viewed 444

I started working in a huge project written in Symfony which is at version 2.8. Upgrading the whole project to SF 3 would take hundreds of hours and it's not possible right now. I came up with an idea to unpack symfony/symfony package to single packages it replaces (key replace in composer.json). It would unlock all 45 packages that are locked on self.version and allow us to upgrade any package step by step if possible.

Example: I have doctrine/orm locked at 2.5.* and cannot ugrade to 2.6 (what will get rid of few bugs and also allow me to upgrade PHP 7.2 --> 7.3) because I have symfony/console locked by symfony/symfony at version 2.8 and doctrine/orm:2.6 requires symfony/console:~3.0.0. However my project would allow to have symfony/console even at version ^3.2 so you can see my point.

I would like to ask you if there are any dangers to the application when attempting to unpack symfony/symfony? So far I can't see any.

P.S. Info for those how want to answer "just require a single package with higher version". Since Composer 1.7.3 it's not possible and will trigger a version conflict.

1 Answers

In such case it will be better to walk in a tiny steps and carefully check results of each step. Of course if whole your project is covered by tests it would be much simpler to do such change, but I don't know if it is.

I would probably do something like this:

  1. Copy composer.json into separate directory
  2. Get exact versions of packages by running composer info
  3. Look into list of packages provided by symfony/symfony e.g. by looking into its own composer.json or by looking at its page on Packagist.
  4. Replace symfony/symfony in copied composer.json with individual packages of same versions as you currently have.
  5. Run composer install and compare resulted set of actually installed packages with packages installed for your project. Simplest way is to compare output of composer info from both directories. You can also use something like composer info | awk -F ' ' '{print $1 " " $2}' | sort to get sorted list of packages and their versions so it will be easier to compare.
  6. Tune packages list and version constraints until you will achieve same results from composer info for both actual project and your new composer.json.
  7. Copy composer.json back into main project. By this time you will be able to install same vendor packages but will be able to control them separately.
  8. Go on with package versions tuning but don't forget to apply minimal changes at a time and test (hopefully by running auto-tests) each change separately.

I hope you know composer why command that allows you to examine package dependencies so you will understand better which packages will get affected by changing version of some particular package.

Good luck with this task because careful upgrade may take quite some time.

Related