Composer set php version

Use Composer with a specific PHP version

Are you using different PHP versions on your local development machine just like me? Then you might have encountered the following error when installing packages with composer, again, just like me.

$ composer require intervention/image:^2.7 . Your requirements could not be resolved to an installable set of packages. Problem 1 - Root composer.json requires php ^7.4 but your php version (8.1.5) does not satisfy that requirement. . 

Composer defaults to the default PHP version. That is, the shebang comment at the top of the executable composer file indicates that the php binary should be used.

You can find out which version this is by running php —version on your terminal.

Now, in order to use the PHP version of your preference you should run the composer binary with the desired php binary. For this you need the exact path to the composer binary. On my machine the composer binary is located at /usr/local/bin/composer .

Thus the command would look the following for me. Using PHP version 7.4.

php7.4 /usr/local/bin/composer require intervention/image:2.7.2 

To find out where composer is installed on your machine you can run which composer in your terminal:

$ which composer /usr/local/bin/composer 

To make this a bit easier you can make this a one step process as well.

$ php7.4 $(which composer) require intervention/image:2.7.2 

Источник

Configuring PHP Version with Composer

I recently wrote a post about updating to PHP 7.4. This is great! Exciting! Progress! But, it introduces some interesting challenges, especially once you’ve updated your host machine to a new version of PHP. Why? Well, for one, composer assumes that the version of PHP on the machine you are running on is the “right” version of PHP.

For instance, here’s a scenario where I updated my virtual machine to PHP 7.4 and I set PHP requirements inside my composer.json file to be PHP 7.4 BUT I had not yet updated my host machine to PHP 7.4:

Your requirements could not be resolved to an installable set of packages.

Problem 1

— Root composer.json requires php >=7.4 but your php version (7.3.14) does not satisfy that requirement.

You can also get into this problem in reverse, where you have updated your host machine to PHP 7.4 but not yet updated a project to PHP 7.4 (still at 7.2 or 7.3) and you accidentally do the upgrade.

There are a couple of ways composer impacts PHP version. Let’s dig into those!

PHP as a Dependency

Did you know you can add PHP as an a dependency right in the composer.json file? Well you can! And it’s definitely recommended, as it helps to make sure that you get the right version of other dependencies. If your project is running PHP 7.4 you want to make sure that all of your other dependencies work with PHP 7.4.

You add this just like any other dependency:

Then you can just run composer update php —with-all-dependencies just like you would anything else.

Note: if you are receiving the error above about the compser.json requirements, sometimes this is an indication that you either SHOULD update your host PHP or that you should be working inside your VM. In my case, all I had to do to resolve that issue was to run the composer command inside the lando vm (so lando composer update [runs inside] vs. composer update [runs outside]).

PHP as a Platform Config

In the updating scenario I discussed previously, platform config will help make sure that your host PHP version and project PHP version stay in their lane.

By doing this, you will essentially make sure that even if you have PHP 7.4 on your host, this project will remain at PHP 7.3. Remember, «php»: «>=7.3» as a requirement CAN MEAN PHP 7.4. So, by having «php»: «>=7.3» as a requirement and «php»: «7.3» as a platform config that will lock the project to PHP 7.3.

In Conclusion

This definition process is super useful when you have a large number of developers that aren’t working in a consistent environment (e.g. a common VM config). Any time you have folks that have the potential for variable PHP configs between machines, these additions to your composer.json fill will hopefully ensure a more stable composer experience.

Источник

Enforcing a PHP Version for Installed Composer Packages

If your development and production environments don’t match you can easily get tripped up when the time comes to deploy to the live server. It’s not too uncommon for developers to find themselves working with one version of PHP and using another in an app or website’s final destination. If you use Composer to manage PHP packages it would be nice to be able to take this into account to avoid any nasty surprises post deployment. Thankfully Composer has this covered.

We can tell Composer what version of PHP we are supporting with our app/website by using the platform configuration in our composer.json file.

In this example we are faking the version of PHP to 5.6.1. This means that whenever we try and install or update a package with Composer the faked platform version of PHP will be taken into account rather than the version of PHP being used on the command-line we are running Composer from. This is really useful if our production environment uses a different setup to the one we are developing on. For example, you may be using an up to date version of PHP 7 locally, but deploy to a server still using 5.6.

Another way of setting this is from the command-line.

composer config platform.php 5.6.1

This will set the platform option in the composer.json file for us. In this example it would add PHP 5.6.1 to the JSON file just like in the previous example. You can also use the -g flag to set this globally.

On a Composer package platform requirements are added just like package dependencies. So for example, if we have a package that requires a minimum of PHP 7.1.0 the composer.json file would look like:-

This is what Composer will use when installing and updating packages when our project has a platform configuration.

Note that when adding a minimum PHP requirement we add this as a dependency using the require key, whereas setting the platform setup uses platform under the config options.

When it comes to installing and updating packages you may at times want to ignore the platform requirements. For example, when adding or updating a dev dependency that will never be installed on the production environment. For this we can use the —ignore-platform-reqs flag.

composer update phpunit/phpunit --ignore-platform-reqs

Although using the platform configuration in composer.json might not catch all unsuitable packages when using Composer it should hopefully catch most incompatible code that could otherwise have found their way onto your production environment. This has been a life saver for me in the past and helped me avoid many headaches.

Источник