Doctrine/Common 2.8 requires PHP ~7.1

See #2887000: composer.json does not constrain Symfony components to minor and patch versions that are compatible with Drupal before you go too far with a patch :)

Hi, the linked issue #2887000: composer.json does not constrain Symfony components to minor and patch versions that are compatible with Drupal is actually not the same - the plan there is to constrain Symfony components to 3.2 because Drupal actually breaks (or broke, at the time) with 3.3. (Though looking at the upgrade issue #2874909: Update Symfony components to 3.3.* it now seems that the only remaining problems are deprecation notices, so I don't know if the constraint is still needed.)

What we have here is composer installing the latest version supported by the current platform - which, if you're using PHP7, can result in packages that require PHP7.

This is only a problem if your dev environment and the target/production environment have different PHP versions - but you can solve this by explicitly setting the target PHP version in your project's composer.json file:

@@ -14,7 +15,8 @@
     "prefer-stable": true,
     "config": {
         "preferred-install": "dist",
-        "autoloader-suffix": "Drupal8"
+        "autoloader-suffix": "Drupal8",
+        "platform": {"php": "5.5.9"}
     },
     "extra": {
         "_readme": [

After setting this, composer will enforce compatibility with PHP 5.5.9 regardless of whether you're using PHP7.

One other thing we can do is to explicitly specify

"doctrine/common": "^2.5<2.8",

There is an existing issue to add the minimum php version configuration, I think this could be a duplicate of that if we decide to not do anything doctrine specific?

#2843328: Enforce minimum PHP version in composer dependencies

You'll potentially have problems not only with doctrine/common but a few other packages too:

    "require": {
        ...
        "doctrine/annotations": "^1.3 <1.4",
        "doctrine/cache": "<1.7",
        "doctrine/collections": "^1.3 <1.4",
        "doctrine/common": "^2.6 <2.7",
        "doctrine/dbal": "^2.5",
        "doctrine/doctrine-bundle": "^1.6",
        "doctrine/inflector": "<1.2",
        "doctrine/orm": "^2.5",
        ...
    },

This'll force doctrine to switch back to PHP 5.5 compatibility, it works gracefully with a Symfony fullstack 3.3 so it should work with Drupal 8 too.

This composer.json sample is extracted from a real client project I maintain, whose production is still PHP 5.5.

Super-duper -1 on config platform fake-out: #2843328-22: Enforce minimum PHP version in composer dependencies

We know why we can't use doctrine/common 2.8, so we should specify it.

I have added the following to my composer.json (inside "config")

"platform": {
     "php": "5.6"
 }

But I am still getting issues,

doctrine/instantiator 1.1.0 requires php ^7.1 -> your PHP version (7.1.5) overridden by "config.platform.php" version (5.6) does not satisfy that requirement.

Is there something else I need to be doing?

Do you get that message after running composer install or composer update? You should run the latter.

Adding those lines only prevents you from getting new packages in the future. If you had already updated to PHP7+ packages, you will need to revert your changes to composer.lock to get back to an installable state.

Not necessarily revert, just launching composer update as fjgarlin said, so that composer.lock reflects your changes in composer.json.

I ran into this issue as well. The patch seemed to work as advertised when running composer on the machine with 5.6.

I've had the same issue here and path #11 worked like a charm.

See #12.

So @alexrayu linked to this issue from the PHP minimum requirement documentation: https://www.drupal.org/node/2891690/discuss#comment-12296385

I'm seeing a failure in this travis-ci test set up to test composer-based bounds checks: https://travis-ci.org/paul-m/drupal_dependency_bounds_test/jobs/287060375

This fail says that Composer is able to resolve all the dependencies under PHP 5.5.9 (using composer update --prefer-lowest and also without), which means this issue isn't really a problem.

But then tests fail like this:

There was 1 error:
1) Drupal\Tests\migrate\Unit\process\FormatDateTest::testTransform with data set "timezone" (array('Y-m-d\TH:i:sO', 'Y-m-d\TH:i:s', 'America/Managua'), '2004-12-19T10:19:42-0600', '2004-12-19T10:19:42')
DateTime::setTimezone(): Can only do this for zones with ID for now
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/vendor/symfony/phpunit-bridge/DeprecationErrorHandler.php:73
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:318
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:238
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:238
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/modules/migrate/src/Plugin/migrate/process/FormatDate.php:101
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/modules/migrate/tests/src/Unit/process/FormatDateTest.php:75
--
There were 4 failures:
1) Warning
The data provider specified for Drupal\Tests\Component\Datetime\DateTimePlusTest::testDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
2) Warning
The data provider specified for Drupal\Tests\Component\Datetime\DateTimePlusTest::testInvalidDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
3) Warning
The data provider specified for Drupal\Tests\Core\Datetime\DrupalDateTimeTest::testDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
4) Warning
The data provider specified for Drupal\Tests\Core\Datetime\DrupalDateTimeTest::testInvalidDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now

This looks like some of the dataProvider code is malformed in some way for the Datetime component, which is then using deprecated code in some way (see that the error is thrown by DeprecatedErrorHandler).

This only shows up in the PHP 5.5.9 test.

Anyway, it doesn't show that we need to constrain versions on doctrine/common. If you run composer update under PHP 7.1, then Composer will use the best fit for that platform, which then probably show a minimum requirement of PHP 7.1 in the lock file for some of the packages.

For core, what we need is either the config:platform:5.5.9 setting (-1 on that from me), or the test in #2843328-51: Enforce minimum PHP version in composer dependencies which looks at core's lock file and verifies that it doesn't require any PHP newer than 5.5.9.

So this is really about updating the tests then.

To confirm #27 from PHP 7.1 requirement for Doctrine packages:

When you run composer update the next time, you’ll automatically receive updates for the packages mentioned above, provided that you are running on PHP 7.1. If you are running an older PHP version, composer will not install a version that requires PHP 7.1, since its requirements are not fulfilled.

A common problem is people running a newer PHP version on their developer machines than on their production servers. In this case, running composer update on a developer machine (with PHP 7.1) might happily pull in an update that simply won’t work when deployed on a production machine running PHP 5.6.

...and it proceeds to provide options on how to mitigate that.

I think it's safe to close this issue since #2843328: Enforce minimum PHP version in composer dependencies is in, meaning we test the lock file to make sure Drupal core can be installed under PHP 5.5. This way core devs won't inadvertently patch composer.lock with an inappropriate dependency.

@Mile23 I think you meant to actually close this issue.