linux – Simulate another environment using the `composer update` command


I have a Symfony2 project with dependencies managed by composer , with their respective composer.json and composer.lock files synchronized between my local machine and the production server through git .

It is known that when running the composer update command, some checks of the machine settings are made before the dependency versions are chosen, since in some cases there are different versions of the same package compatible with different environments.

An example of a multi-version package is symfony/icu , which is responsible for the internationalization of Symfony2 . The version chosen by composer for this package differs between 1.0.0 and 1.2.0 depending on the existence or absence of the lib-icu library on the machine.

Case 1 – Run composer update on the local machine

When I run composer update on my local machine , which has the lib-icu internationalization library, a composer.lock file is created that references version v.1.2.0 of the symfony/icu package.

Problem: The production server does not have the lib-icu library, so when I run composer install from the composer.lock generated earlier, an error is returned regarding the absence of this library.

Case 2 – Run composer update on production server

If, on the other hand, I run composer update on my production server , the automatically chosen dependency of symfony/icu is version v1.0.0 (which works without lib-icu ). In this situation, when running composer install everything works fine, both on the production server and on my local machine.

How to simulate production server environment?

My question is: is there any way I can run composer update on my local machine by forcing composer to use version v1.0.0 of the symfony/icu package, instead of using version v1.2.0 based on my machine's configuration? That is, I want to run composer update on my local machine, and get the same result that I would get if I ran it on the remote server, as if the lib-icu library didn't exist on my local machine.

My composer.json

    "name": "symfony/framework-standard-edition",
    "license": "MIT",
    "type": "project",
    "description": "The \"Symfony Standard Edition\" distribution",
    "autoload": {
        "psr-0": {
            "": "src/",
            "Application": "app/"
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "2.3.*",
        "doctrine/orm": ">=2.2.3,<2.4-dev",
        "doctrine/doctrine-bundle": "1.2.*",
        "twig/extensions": "1.0.*",
        "symfony/assetic-bundle": "2.3.*",
        "symfony/swiftmailer-bundle": "2.3.*",
        "symfony/monolog-bundle": "2.3.*",
        "sensio/distribution-bundle": "2.3.*",
        "sensio/framework-extra-bundle": "2.3.*",
        "sensio/generator-bundle": "2.3.*",
        "incenteev/composer-parameter-handler": "~2.0",
        "sonata-project/admin-bundle": "2.2.7",
        "sonata-project/doctrine-orm-admin-bundle": "2.2.4",
        "sonata-project/easy-extends-bundle": "2.1.3",
        "sonata-project/user-bundle": "2.2.0"
    "scripts": {
        "post-install-cmd": [
        "post-update-cmd": [
    "config": {
        "bin-dir": "bin"
    "minimum-stability": "stable",
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        "branch-alias": {
            "dev-master": "2.3-dev"


I would try to include that package explicitly, passing in the desired version. It is quite possible that this takes precedence over the dependency chain composer is using. I believe that whoever asks for symfony/icu must be asking for a minimal version, using a wildcard ( * ) in the version number, or specifying >= X .

So include in your require key:

"symfony/icu": "1.0.0" // ou 1.0.*
Scroll to Top