# composer/installers: Composer Package Routing for PHP Frameworks > composer/installers is a Composer library for PHP package authors whose packages need framework-specific installation paths. It supports a broad map of package types, but the README also defines its limits: it is unnecessary for frameworks that already work with Composer, and special handling should use a custom installer. **composer/installers** — A Multi-Framework Composer Library Installer - Repository: https://github.com/composer/installers - Stars: 1,439 · Forks: 399 - Language: PHP - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/composer-installers ## The Composer routing problem composer/installers addresses a specific Composer limitation. By default, Composer dependencies live under the vendor directory, which works well for ordinary PHP libraries and for frameworks that support Composer natively. Some framework ecosystems expect modules, plugins, themes, extensions, components, or other assets to be placed in directories defined by the framework. A package author using one of those package types needs Composer to route the package to the expected location. The project is aimed at PHP package authors who should require composer/installers in their own composer.json. Its central idea is a package type to install path map. Composer identifies a package by its declared type, and the library uses that type to determine where the package should be installed. The README also says that users can customize the install path per package and package authors can modify the package name when installing. Those controls are relevant when a framework has multiple conventions or when a package must fit an existing application layout. This is an installation-location library, not a package manager and not a replacement for Composer itself. It changes where Composer places recognized package types. It does not make an unsupported framework supported, and it does not describe a general-purpose mechanism for running migrations, registering extensions, or executing arbitrary post-install operations. The repository contains PHP source, Composer metadata, tests, and static-analysis configuration, while the README focuses on supported framework types and the boundary between mapped installation and custom installers. ## Package types and framework destinations The central design choice is to make installation behavior declarative. A package declares a type such as cakephp-plugin, drupal-module, laravel-library, magento-theme, moodle-*, or one of the many framework-specific identifiers in the README. composer/installers maps that type to a destination associated with the framework. The project therefore avoids requiring every package author to duplicate the same path decision in separate setup code. The supported list is broad, but it is not uniform. Stable types are marked in the README, and changing their paths is described as requiring a new package type. That distinction matters because a stable type is a compatibility surface for package authors. The project lists entries for Akaunting, Asgard, CakePHP, Chef, CiviCrm, CodeIgniter, concrete5, ConcreteCMS, Drupal, ExpressionEngine, Joomla-related names visible in the list, Magento, MODX, MediaWiki, October, PrestaShop, Shopware, SilverStripe, and many others. It also marks some Bitrix types as deprecated while listing newer bitrix-d7 types. The breadth has a cost. A framework name in the table does not by itself prove that every current release uses the same directory layout. The README points readers to the source for Moodle's complete type list, and it separates stable types from types whose paths may be adjusted. An adopter should therefore treat the table as the library's supported routing surface, not as a general claim about current framework conventions. Package names and types must match the conventions expected by the target application. ## What happens during Composer installation The documented data flow begins in a package author's composer.json. The package declares its dependency requirements and Composer package type, then composer/installers is required as part of the package metadata. When Composer installs the dependency, the installer plugin can inspect the package type and select the corresponding install path. The result is a package placed where the framework expects that category of content. The repository layout supports this design. The src/ directory contains the implementation, and tests/ contains the test suite. The project also includes composer.json, phpunit.xml.dist, phpstan.neon.dist, and a static-analysis baseline, which shows that the library is tested and analyzed as PHP source rather than being a shell script or a framework runtime. The README's terminology, especially its reference to a package type to install path map, makes clear that routing metadata is the main mechanism. The README does not document an event sequence, fallback behavior, or a user-facing CLI command for composer/installers. It also does not describe how a custom path or package-name modification is configured. Those details should not be inferred from the high-level description. Consumers need to inspect the relevant installer implementation and package metadata for the exact framework and type they use. The library's value is in avoiding custom installer code for cases that fit its mapping, not in making every Composer installation customizable. ## Installation and first Composer use The README says that PHP package authors should require composer/installers in their composer.json. It does not provide a complete installation command, dependency version, configuration file, or step-by-step first-run example, so no command or configuration block can be reproduced from the available project documentation. The repository's composer.json is the place to inspect for package metadata, and the framework's package type must be selected from the table. For a first real use, the package author should identify the target framework and its exact supported type, then add composer/installers as a requirement in the package's Composer metadata. The package itself must also declare the matching type. After Composer processes the project, the dependency should be placed according to the installer map rather than treated like an ordinary vendor-only library. The expected result is framework-specific placement, not a particular output directory that the README does not specify for every framework. Because no installation command is documented here, the safe first step is to inspect the repository's composer.json and the framework-specific package metadata rather than inventing flags or versions. The README also warns that most modern frameworks work with Composer and install to vendor without this library. A package that already follows that native behavior should not add composer/installers merely because it is a PHP package. ## Composer 2.1 runtime discovery as the alternative The most important alternative is not another third-party installer. With Composer 2.1, Composer\InstalledVersions::getInstalledPackagesByType() can identify installed plugins, modules, and extensions by package type at runtime. The README specifically recommends this method instead of building new custom installers for a new application. Its practical difference is architectural: InstalledVersions discovers packages already installed by Composer, while composer/installers controls where certain packages are installed. This distinction changes the deployment model. InstalledVersions leaves vendor code in the vendor directory and does not require custom installer code. composer/installers is appropriate when the framework requires files outside vendor or when package placement is part of the package's compatibility contract. If the application only needs to know which package types are installed, a custom installer is unnecessary. If it needs genuine custom handling, such as a special procedure that cannot be represented by a known type and destination, the README directs authors to create a Composer custom installer instead. That makes composer/installers a narrow alternative to custom installers, not a universal replacement. The decision should be based on whether the package type is in the supported map and whether the required behavior is only location routing. ## Limitations, maintenance, and license The clearest limitation is that the library cannot cover arbitrary installation requirements. The README states that it is not intended to replace all custom installers. If a package requires special installation handling, the project directs authors to a custom installer. It is also unnecessary for frameworks that natively work with Composer and install packages into vendor. Adding it in those cases adds a dependency without solving a documented placement problem. The supported type table is another constraint. It contains many frameworks, but it also contains deprecated Bitrix types, version-specific labels such as FuelPHP v1.x and FuelPHP v2.x, and a Moodle entry that directs readers to the source for the complete list. A package author must select the exact type rather than infer support from a framework's general name. A framework upgrade can also change the expected destination, while the README does not document a compatibility policy for every framework version. The repository is not archived. Its last push was on 2026-07-01, so the available maintenance signal is recent activity, although the most recent listed release is v2.3.0 from 2024-06-24. Upgrading therefore means checking the release history and validating the destination for the package type in use. The repository lists an MIT license. That identifies the stated licensing model, but it does not replace checking the full LICENSE file and any third-party package licensing separately. ## Conclusion Adopt composer/installers when a package type must be installed outside the default vendor directory and the framework is covered by its type map. Do not add it to applications that only need runtime package discovery, or to packages requiring specialized installation logic. Verify the supported package type, destination path, Composer plugin permissions, and the framework's native installation behavior before changing a production composer.json. ## FAQ ### What does composer/installers do? It is a Composer library for PHP package authors that maps declared package types to framework-specific installation paths. It can also support per-package path customization and package-name modification. ### When do I not need composer/installers? You do not need it when the framework natively supports Composer and installs packages in the default vendor directory. For runtime discovery by package type, Composer 2.1's Composer\InstalledVersions is also the alternative described by the README. ### How do I install a package with a special framework? Require composer/installers in the package's composer.json and declare the framework's supported package type. The README does not provide a complete command or configuration example, so the repository's composer.json and the applicable installer source are the references for exact details. ## Sources - [composer/installers on GitHub](https://github.com/composer/installers) - [Issues](https://github.com/composer/installers/issues) - [License: MIT](https://github.com/composer/installers/blob/main/LICENSE) - [README](https://github.com/composer/installers/blob/main/README.md) - [Releases](https://github.com/composer/installers/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/composer-installers