Composer Installers

Alternative to custom installers with Composer 2.1+

As of Composer 2.1, the Composer\InstalledVersions class has a getInstalledPackagesByType method which can let you figure out at runtime which plugins/modules/extensions are installed.

It is highly recommended to use that instead of building new custom installers if you are building a new application. This has the advantage of leaving all vendor code in the vendor directory, and not requiring custom installer code.

Example composer.json File

This is an example for a CakePHP plugin. The only important parts to set in your composer.json file are "type": "cakephp-plugin" which describes what your package is and "require": { "composer/installers": "~1.0" } which tells composer to load the custom installers.

{
    "name": "you/ftp",
    "type": "cakephp-plugin",
    "require": {
        "composer/installers": "~1.0"
    }
}

This would install your package to the Plugin/Ftp/ folder of a CakePHP app when a user runs php composer.phar install.

So submit your packages to packagist.org!

Custom Install Names

If you’re a package author and need your package to be named differently when installed consider using the installer-name extra.

For example you have a package named shama/cakephp-ftp with the type cakephp-plugin. Installing with composer/installers would install to the path Plugin/CakephpFtp. Due to the strict naming conventions, you as a package author actually need the package to be named and installed to Plugin/Ftp. Using the following config within your package composer.json will allow this:

{
    "name": "shama/cakephp-ftp",
    "type": "cakephp-plugin",
    "extra": {
        "installer-name": "Ftp"
    }
}

Please note the name entered into installer-name will be the final and will not be inflected.

Disabling installers

There may be time when you want to disable one or more installers from composer/installers. For example, if you are managing a package or project that uses a framework specific installer that conflicts with composer/installers but also have a dependency on a package that depends on composer/installers.

Installers can be disabled for your project by specifying the extra installer-disable property. If set to true, "all", or "*" all installers will be disabled.

{
    "extra": {
        "installer-disable": true
    }
}

Otherwise a single installer or an array of installers may be specified.

{
    "extra": {
        "installer-disable": [
            "cakephp",
            "drupal"
        ]
    }
}

Note: Using a global disable value (true, "all", or "*") will take precedence over individual installer names if used in an array. The example below will disable all installers.

{
    "extra": {
        "installer-disable": [
          "drupal",
          "all"
        ]
    }
}

Should we allow dynamic package types or paths? No

What are they? The ability for a package author to determine where a package will be installed either through setting the path directly in their composer.json or through a dynamic package type: "type": "framework-install-here".

It has been proposed many times. Even implemented once early on and then removed. Installers won’t do this because it would allow a single package author to wipe out entire folders without the user’s consent. That user would then come here to yell at us.

Anyone still wanting this capability should consider requiring https://github.com/oomphinc/composer-installers-extender.