Runtime Composer utilities - Composer (2024)

• Autoload
• Installed versions
  • Knowing whether package X (or virtual package) is present
  • Knowing whether package X is installed in version Y
  • Knowing the version of package X
  • Knowing a package's own installed version
  • Knowing the path in which a package is installed
  • Knowing which packages of a given type are installed
• Platform check
• Autoloader path in binaries
• Binary (bin-dir) path in binaries

While Composer is mostly used around your project to install its dependencies,there are a few things which are made available to you at runtime.

If you need to rely on some of these in a specific version, you can requirethe composer-runtime-api package.

Autoload#

The autoloader is the most used one, and is already covered in ourbasic usage guide. It is available in allComposer versions.

Installed versions#

composer-runtime-api 2.0 introduced a new Composer\InstalledVersions class which offersa few static methods to inspect which versions are currently installed. This isautomatically available to your code as long as you include the Composer autoloader.

The main use cases for this class are the following:

Knowing whether package X (or virtual package) is present#

\Composer\InstalledVersions::isInstalled('vendor/package'); // returns bool\Composer\InstalledVersions::isInstalled('psr/log-implementation'); // returns bool

As of Composer 2.1, you may also check if something was installed via require-dev or not bypassing false as second argument:

\Composer\InstalledVersions::isInstalled('vendor/package'); // returns true assuming this package is installed\Composer\InstalledVersions::isInstalled('vendor/package', false); // returns true if vendor/package is in require, false if in require-dev

Note that this can not be used to check whether platform packages are installed.

Knowing whether package X is installed in version Y#

Note: To use this, your package must require "composer/semver": "^3.0".

use Composer\Semver\VersionParser;\Composer\InstalledVersions::satisfies(new VersionParser, 'vendor/package', '2.0.*');\Composer\InstalledVersions::satisfies(new VersionParser, 'psr/log-implementation', '^1.0');

This will return true if e.g. vendor/package is installed in a version matching2.0.*, but also if the given package name is replaced or provided by some otherpackage.

Knowing the version of package X#

Note: This will return null if the package name you ask for is not itself installedbut merely provided or replaced by another package. We therefore recommend using satisfies()in library code at least. In application code you have a bit more control and it is lessimportant.

// returns a normalized version (e.g. 1.2.3.0) if vendor/package is installed,// or null if it is provided/replaced,// or throws OutOfBoundsException if the package is not installed at all\Composer\InstalledVersions::getVersion('vendor/package');

// returns the original version (e.g. v1.2.3) if vendor/package is installed,// or null if it is provided/replaced,// or throws OutOfBoundsException if the package is not installed at all\Composer\InstalledVersions::getPrettyVersion('vendor/package');

// returns the package dist or source reference (e.g. a git commit hash) if vendor/package is installed,// or null if it is provided/replaced,// or throws OutOfBoundsException if the package is not installed at all\Composer\InstalledVersions::getReference('vendor/package');

Knowing a package's own installed version#

If you are only interested in getting a package's own version, e.g. in the source of acme/foo you wantto know which version acme/foo is currently running to display that to the user, then it isacceptable to use getVersion/getPrettyVersion/getReference.

The warning in the section above does not apply in this case as you are sure the package is presentand not being replaced if your code is running.

It is nonetheless a good idea to make sure you handle the null return value as gracefully aspossible for safety.

A few other methods are available for more complex usages, please refer to thesource/docblocks of the class itself.

Knowing the path in which a package is installed#

The getInstallPath method to retrieve a package's absolute install path.

Note: The path, while absolute, may contain ../ or symlinks. It isnot guaranteed to be equivalent to a realpath() so you should run arealpath on it if that matters to you.

See Also

'Music is a need for me': Violinist discusses composing an album under ISIS

// returns an absolute path to the package installation location if vendor/package is installed,// or null if it is provided/replaced, or the package is a metapackage// or throws OutOfBoundsException if the package is not installed at all\Composer\InstalledVersions::getInstallPath('vendor/package');

Available as of Composer 2.1 (i.e. composer-runtime-api ^2.1)

Knowing which packages of a given type are installed#

The getInstalledPackagesByType method accepts a package type (e.g. foo-plugin) and liststhe packages of that type which are installed. You can then use the methods above to retrievemore information about each package if needed.

This method should alleviate the need for custom installers placing plugins in a specific pathinstead of leaving them in the vendor dir. You can then find plugins to initialize at runtimevia InstalledVersions, including their paths via getInstallPath if needed.

\Composer\InstalledVersions::getInstalledPackagesByType('foo-plugin');

Available as of Composer 2.1 (i.e. composer-runtime-api ^2.1)

Platform check#

composer-runtime-api 2.0 introduced a new vendor/composer/platform_check.php file, whichis included automatically when you include the Composer autoloader.

It verifies that platform requirements (i.e. php and php extensions) are fulfilledby the PHP process currently running. If the requirements are not met, the scriptprints a warning with the missing requirements and exits with code 104.

To avoid an unexpected white page of death with some obscure PHP extension warning inproduction, you can run composer check-platform-reqs as part of yourdeployment/build and if that returns a non-0 code you should abort.

The default value is php-only which only checks the PHP version.

If you for some reason do not want to use this safety check, and would ratherrisk runtime errors when your code executes, you can disable this by setting theplatform-check config option to false.

If you want the check to include verifying the presence of PHP extensions,set the config option to true. ext-* requirements will then be verifiedbut for performance reasons Composer only checks the extension is present,not its exact version.

lib-* requirements are never supported/checked by the platform check feature.

Autoloader path in binaries#

composer-runtime-api 2.2 introduced a new $_composer_autoload_path globalvariable set when running binaries installed with Composer. Read moreabout this on the vendor binaries docs.

This is set by the binary proxy and as such is not made available to projectsby Composer's vendor/autoload.php, which would be useless as it would point backto itself.

Binary (bin-dir) path in binaries#

composer-runtime-api 2.2.2 introduced a new $_composer_bin_dir globalvariable set when running binaries installed with Composer. Read moreabout this on the vendor binaries docs.

This is set by the binary proxy and as such is not made available to projectsby Composer's vendor/autoload.php.

← Config | Community →

Found a typo? Something is wrong in this documentation? Fork and edit it!