Laravel Composer sees wrong PHP Version

In case it helps someone in the future, I ran into this problem while trying to run composer update from inside PHPStorm (2017.2). I tried the above suggestions, but none ofthem worked. I have multiple versions of PHP installed (5.6, 7.0, 7.1) all added under PHPStorm settings, so I can switch based on project requirements. Regardless of selected CLI interpreter setting, it always looks to PHP 7.0 when calling composer. Running composer in a terminal outside of PHPStorm works without issue (references the path configured version, 7.1). In my case, this feels like a PHPStorm bug.

On my HostGator shared hosting, I was able to overcome this problem by creating Aliases in my .bashrc file for the php version I wanted to use:

alias php='/opt/php71/bin/php'
alias composer="/opt/php71/bin/php ~/bin/composer/composer.phar"

Remember to source after editing the .bashrc file: 'source ~/.bashrc'

I've had this problem too. If you don't want to update all your composer packages, you can solve this issue by manually changing the composer.lock file and writing your actual PHP version in platform > php in the JSON object.

Example

...
"platform": {
    "php": "7.1"
}
...

Although it works, the most recommended way to do this would be deleting your composer.lock file, changing the platform > php version in composer.json and then executing composer install.

composer clear-cache
composer self-update
composer update --ignore-platform-reqs
or
composer install --ignore-platform-reqs

additional information and response to @nicohase, Nico, you are correct when you state that composer is not using the same php executable as apache. Why would composer ensure that php-cli meets the requirements of the other required packages? It wouldn't and doesn't. The user is administering composer with php-cli, which inherently means that they are compatible. Composer is checking to ensure that the version of php that is running on the webserver and the other packages are compatible.

Now, as to why, both the method that I listed and the other post suggests, are both likely solutions. Composer caches information regarding the system, php and the packages that are installed for two reasons, 1. continuity.. 2. version history. If composer modified its own cache files when external changes occurred, it would be difficult to know which packages versions were compatible with each other, and when.

So, composer is not checking the php version when an update or install is occurring, it references its cache. Apache likely greps any references to php versions that are being disabled by the user, it would find a reference in composer's cache files. My suggestion recommends that the cache be deleted for that reason. Additionally, the

composer --self-update

tells composer to update itself, as opposed to the packages it manages ...

composer update

at that point if php had been initially installed by way of yum/apt, and then upgraded by easy apache, the --ignore-platform-reqs flag will circumvent any rpm exclude functionality that may still exist, and allow the install or update of the composer packages.