Description
This is for PHP package authors to require in their composer.json. It will
install their package to the correct location based on the specified package
type.
The goal of installers is to be a simple package type to install path map.
Users can also customize the install path per package and package authors can
modify the package name upon installing.
The following frameworks natively work with Composer and will be
installed to the default vendor directory. composer/installers
is not needed to install packages with these frameworks:
Composer Installers alternatives and similar libraries
Based on the "Dependency Management" category.
Alternatively, view Composer Installers alternatives based on common mentions on social networks and blogs.
Cloudways Early Bird Offer
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of Composer Installers or a related project?
README
A Multi-Framework Composer Library Installer
This is for PHP package authors to require in their composer.json
. It will
install their package to the correct location based on the specified package
type.
The goal of Installers is to be a simple package type to install path map. Users can also customize the install path per package and package authors can modify the package name upon installing.
Installers isn't intended on replacing all custom installers. If your package requires special installation handling then by all means, create a custom installer to handle it.
Natively Supported Frameworks:
Most frameworks these days natively work with Composer and will be
installed to the default vendor
directory. composer/installers
is not needed to install packages with these frameworks.
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.
Current Supported Package Types
Stable types are marked as bold, this means that installation paths for those type will not be changed. Any adjustment for those types would require creation of brand new type that will cover required changes.
Framework | Types |
---|---|
Akaunting | akaunting-module |
Asgard | asgard-module asgard-theme |
Attogram | attogram-module |
AGL | agl-module |
Bonefish | bonefish-package |
AnnotateCms | annotatecms-module annotatecms-component annotatecms-service |
Bitrix | bitrix-module (deprecated) bitrix-component (deprecated) bitrix-theme (deprecated) bitrix-d7-module bitrix-d7-component bitrix-d7-template |
CakePHP 2+ | cakephp-plugin |
Chef | chef-cookbook chef-role |
CiviCrm | civicrm-ext |
CCFramework | ccframework-ship ccframework-theme |
Cockpit | cockpit-module |
CodeIgniter | codeigniter-library codeigniter-third-party codeigniter-module |
concrete5 | concrete5-core concrete5-package concrete5-theme concrete5-block concrete5-update |
Croogo | croogo-plugin croogo-theme |
Decibel | decibel-app |
Dframe | dframe-module |
DokuWiki | dokuwiki-plugin dokuwiki-template |
Dolibarr | dolibarr-module |
Drupal | drupal-core drupal-module drupal-theme drupal-library drupal-profile drupal-database-driver drupal-drush drupal-custom-theme drupal-custom-module drupal-custom-profile drupal-drupal-multisite drupal-console drupal-console-language drupal-config |
Elgg | elgg-plugin |
Eliasis | eliasis-component eliasis-module eliasis-plugin eliasis-template |
ExpressionEngine 3 | ee3-addon ee3-theme |
eZ Platform | ezplatform-assets ezplatform-meta-assets |
FuelPHP v1.x | fuel-module fuel-package fuel-theme |
FuelPHP v2.x | fuelphp-component |
Grav | grav-plugin grav-theme |
Hurad | hurad-plugin hurad-theme |
ImageCMS | imagecms-template imagecms-module imagecms-library |
iTop | itop-extension |
Kanboard | kanboard-plugin |
Known | known-plugin known-theme known-console |
KodiCMS | kodicms-plugin kodicms-media |
Kohana | kohana-module |
Lan Management System | lms-plugin lms-template lms-document-template lms-userpanel-module |
Laravel | laravel-library |
Lavalite | lavalite-theme lavalite-package |
Lithium | lithium-library lithium-source |
Magento | magento-library magento-skin magento-theme |
majima | majima-plugin |
Mako | mako-package |
MantisBT | mantisbt-plugin |
Matomo | matomo-plugin |
Mautic | mautic-core mautic-plugin mautic-theme |
Maya | maya-module |
MODX | modx-extra |
MODX Evo | modxevo-snippet modxevo-plugin modxevo-module modxevo-template modxevo-lib |
MediaWiki | mediawiki-extension |
Miaoxing | miaoxing-plugin |
October | october-module october-plugin october-theme |
OntoWiki | ontowiki-extension ontowiki-theme ontowiki-translation |
OXID | oxid-module oxid-theme oxid-out |
Osclass | osclass-plugin osclass-theme osclass-language |
MODULEWork | modulework-module |
Moodle | moodle-* (Please check source for all supported types) |
Pantheon | quicksilver-script quicksilver-module |
Piwik | piwik-plugin |
Phifty | phifty-bundle phifty-framework phifty-library |
phpBB | phpbb-extension phpbb-style phpbb-language |
Plentymarkets | plentymarkets-plugin |
PPI | ppi-module |
Prestashop | prestashop-module prestashop-theme |
Puppet | puppet-module |
Porto | porto-container |
ProcessWire | processwire-module |
RadPHP | radphp-bundle |
REDAXO | redaxo-addon |
REDAXO bestyle-plugin | redaxo-bestyle-plugin |
REDAXO V5.* | redaxo5-addon |
REDAXO V5.* bestyle-plugin | redaxo5-bestyle-plugin |
ReIndex | reindex-plugin reindex-theme |
Roundcube | roundcube-plugin |
shopware | shopware-backend-plugin shopware-core-plugin shopware-frontend-plugin shopware-theme shopware-plugin shopware-frontend-theme |
SilverStripe | silverstripe-module silverstripe-theme |
SiteDirect | sitedirect-module sitedirect-plugin |
SMF | smf-module smf-theme |
Starbug | starbug-module starbug-theme starbug-custom-module starbug-custom-theme |
SyDES | sydes-module sydes-theme |
Sylius | sylius-theme |
TAO | tao-extension |
TastyIgniter | tastyigniter-module tastyigniter-extension tastyigniter-theme |
Tusk | tusk-task tusk-command tusk-asset |
UserFrosting | userfrosting-sprinkle |
Vanilla | vanilla-plugin vanilla-theme |
Vgmcp | vgmcp-bundle vgmcp-theme |
WHMCS | whmcs-addons whmcs-fraud whmcs-gateways whmcs-notifications whmcs-registrars whmcs-reports whmcs-security whmcs-servers whmcs-social whmcs-support whmcs-templates whmcs-includes |
Winter CMS | winter-module winter-plugin winter-theme |
Wolf CMS | wolfcms-plugin |
WordPress | wordpress-plugin wordpress-theme wordpress-muplugin wordpress-dropin |
YAWIK | yawik-module |
Zend | zend-library zend-extra zend-module |
Zikula | zikula-module zikula-theme |
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 Paths
If you are requiring a package which has one of the supported types you can
override the install path with the following extra in your composer.json
:
{
"extra": {
"installer-paths": {
"your/custom/path/{$name}/": ["shama/ftp", "vendor/package"]
}
}
}
You can determine a non-standard installation path for all packages of a
particular type with the type:
prefix. The type must be one of types
listed on the supported list above.
{
"extra": {
"installer-paths": {
"your/custom/path/{$name}/": ["type:wordpress-plugin"]
}
}
}
You can also install all packages by a particular vendor to a custom
installation path by using the vendor:
prefix. The path will still
only apply to packages by the vendor with a type in the supported list.
{
"extra": {
"installer-paths": {
"your/custom/path/{$name}/": ["vendor:my_organization"]
}
}
}
These would use your custom path for each of the matching packages. The
available variables to use in your paths are: {$name}
, {$vendor}
, {$type}
.
Note: If multiple custom installer-paths match for the same package, the first one which matches will be used.
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.