1

So, I recently updated my symfony project to the 4.3 version, and since it caused problems, I downgraded it to 4.2.9. But despite my efforts, and various options of composer, it keeps installing its dependencies on 4.3, (twig, security, yaml...) Even though its composer.json file shows clearly that it should use the same version. I removed vendor, cleared the cache, removed composer.lock and symfony.lock used the --no-cache option, specifically set the symfony version in composer to 4.2.9 precisely, but it always install the 4.3, which is kinda frustrating. If I checkout an old composer.lock and make an install, it works, but the update will still install 4.3, even though I set 4.2.9 in the json for symfony.

Is there a way out ? Thanks

I'm using

composer update --no-cache --dry-run

to see what we be installed without actually installing it

And this is my composer.json

{
    "type": "project",
    "license": "proprietary",
    "require": {
        "php": "^7.1.3",
        "ext-iconv": "*",
        "friendsofsymfony/jsrouting-bundle": "^2.3",
        "sensio/framework-extra-bundle": "^5.1",
        "symfony/console": "^4.0",
        "symfony/flex": "^1.0",
        "symfony/form": "^4.0",
        "symfony/framework-bundle": "4.2.9",
        "symfony/lts": "^4@dev",
        "symfony/monolog-bundle": "^3.3",
        "symfony/orm-pack": "^1.0",
        "symfony/security-bundle": "^4.1",
        "symfony/translation": "^4.0",
        "symfony/twig-bundle": "^4.0",
        "symfony/validator": "^4.0",
        "symfony/webpack-encore-pack": "^1.0",
        "symfony/yaml": "^4.0"
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.0",
        "sensiolabs/security-checker": "^5.0",
        "symfony/debug-bundle": "^4.1",
        "symfony/dotenv": "^4.0",
        "symfony/maker-bundle": "^1.9",
        "symfony/profiler-pack": "^1.0",
        "symfony/web-server-bundle": "^4.0"
    },
    "config": {
        "preferred-install": {
            "*": "dist"
        },
        "sort-packages": true
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\\Tests\\": "tests/"
        }
    },
    "replace": {
        "symfony/polyfill-iconv": "*",
        "symfony/polyfill-php71": "*",
        "symfony/polyfill-php70": "*",
        "symfony/polyfill-php56": "*"
    },
    "scripts": {
        "auto-scripts": {
            "cache:clear": "symfony-cmd",
            "assets:install --symlink --relative %PUBLIC_DIR%": "symfony-cmd",
            "security-checker security:check": "script"
        },
        "post-install-cmd": [
            "@auto-scripts"
        ],
        "post-update-cmd": [
            "@auto-scripts"
        ]
    },
    "conflict": {
        "symfony/symfony": "*"
    },
    "extra": {
        "symfony": {
            "allow-contrib": false,
            "require": "4.2.9"
        }
    }
}

Note: I'm not talking about the dependencies of my own composer.json, but the ones installed by symfony, such as http-foundation or http-kernel.

FTW
  • 922
  • 1
  • 7
  • 19

2 Answers2

0

composer.lock It maintains the exact versions that were previously used. there is a difference between 'composer update' and 'composer install'

bring back composer.lock

git checkout -- composer.lock
rm -rf vendor 
composer install
Isaac Limón
  • 1,940
  • 18
  • 15
  • Indeed but I remove composer.lock beforehand, it should not be an issue. I could take back a previous one sure but... what about on the next update ? I don't want the version to go back to 4.3 – FTW Jun 03 '19 at 22:43
  • Remove composer.lock and the vendor folder. Then try to install again but w/o any scripts and plugins: `$ composer install --no-plugins --no-scripts`. – hakre Jun 03 '19 at 22:52
  • Doesn't change anything, (I added the --dry-run option) – FTW Jun 03 '19 at 23:10
0

For the dependencies you specified ^4.0 as the version, which means the newest version that starts with 4. If the latest update caused problems, you should change these constraints to something more restrictive, for example the exact version that you were using before (4.2.9). Then run composer update and the correct versions should be installed.

LorenzSchaef
  • 1,523
  • 10
  • 16
  • Not every dependencie is listed in my own composer.json, I did as you said and indeed these one are below 4.2.9; but the others (http-foundation, http-kernel, and many others) are still 4.3.0. – FTW Jun 04 '19 at 17:44
  • That's because they are dependencies of the main symfony package and there they are listed with a more loose constraint. So composer takes the newest version within that constraint. If you want to force them to stay at 4.2.9 you will have to list them in your own composer.json as well. – LorenzSchaef Jun 05 '19 at 07:51
  • Well that's the thing, the constraint doesn't seem lose at all: https://github.com/symfony/symfony/blob/v4.2.9/composer.json It's apparently asking to get the same version of the dependencies than symfony's one – FTW Jun 05 '19 at 12:13
  • that composer.json doesn't require these other packages, it replaces them, which basically means that their code is included in the main package. so I guess there's not much you can do about it other than downgrading the main package even further. – LorenzSchaef Jun 06 '19 at 06:07
  • Is it really the usual behavior ? I'm pretty sure it wasn't like before (okay almost), and since the version displayed in the debug toolbar is taken from http-kernel, it means it can be unaccurate (which is currently the case) – FTW Jun 07 '19 at 08:16