Composer installing incompatible package

Question

I have a composer.json file that includes the following:

"require": {
    "php": "~7.3.0",
    "ext-imagick": "*",
    "ext-apcu": "*",
    "ext-json": "*",
    "ext-blackfire": "*",
    "doctrine/doctrine-migrations-bundle": "^1.3",

The later use of --ignore-platform-reqs relates to the docker image not having those extensions, but the Heroku environment does.

The latter is requiring a package, which requires another package.

$ composer why ocramius/package-versions
doctrine/orm            v2.7.2  requires  ocramius/package-versions (^1.2)
ocramius/proxy-manager  2.8.0   requires  ocramius/package-versions (^1.8.0)

$ composer why ocramius/proxy-manager
doctrine/migrations  v1.8.1  requires  ocramius/proxy-manager (^1.0|^2.0)

This is installing code that uses PHP 7.4's property type declarations. This throws a big ugly error in PHP 7.3.

$ php -d memory_limit=-1 composer.phar update --ignore-platform-reqs
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 195 installs, 0 updates, 0 removals
  - Installing ocramius/package-versions (1.8.0): Loading from cache

Parse error: syntax error, unexpected 'string' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in 
             /var/www/project/vendor/ocramius/package-versions/src/PackageVersions/Installer.php
             on line 33

Why am I always getting this version of ocramius/package-versions and how to do I prevent this error (and that package version) from happening?

Why not use the common techniques for requiring only compatible packages? Setting the PHP platform is documented for this since years — Nico Haase, May 06 '20 at 06:36
Does this answer your question? [How to always use ignore-platform-reqs flag when running composer?](https://stackoverflow.com/questions/35273522/how-to-always-use-ignore-platform-reqs-flag-when-running-composer) — Nico Haase, May 06 '20 at 06:37
Thanks for the link; it says in less detail what my answer below states, without explaining why it allowed 7.4 packages into vendors. You would have to explain "common techniques for requiring only compatible packages". — Jared Farrish, May 06 '20 at 13:08

Jared Farrish · Accepted Answer · 2020-05-06T13:14:34.760

The solution for me was to remove --ignore-platform-reqs. For any forward-leaning packages (any Ocramius package, for instance), this will either fail hard like this did, or you'll have several strange bugs you can't seem to track down the cause of.

What --ignore-platform-reqs does is it switches off the checks Composer makes to ensure that only packages compatible with the environment works. In this case, the offending package had a recent update to use PHP 7.4, and happened to use the new property type declarations in the Composer installer.

I had been battling several other weirdnesses (like the Doctrine's Entity Manager failing randomly, another Ocramius-related package), which all went away by removing the flag when I ran Composer. Whatever the reason I needed it years ago, I no longer do.

If you feel you need it, check out config.platform which seems to allow you to lie to Composer, or work to remove needing that flag altogether (why-ever you think you need it, get over it if possible).

Lets you fake platform packages (PHP and extensions) so that you can emulate a production env or define your target platform in the config. Example: {"php": "7.0.3", "ext-something": "4.0.3"}.

https://getcomposer.org/doc/06-config.md#platform

Composer installing incompatible package

1 Answers1