Weave Code
Code Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Composer Installers Extender

Composer Installers Extender Laravel Package

oomphinc/composer-installers-extender

Extends Composer Installers to add custom installer types and paths without forking. Define extra installer mappings for plugins/themes/modules and other packages, keeping your project’s directory structure consistent across Composer installs.

View on GitHub
Deep Wiki
Context7

Extend the composer/installers plugin to accept any arbitrary package type.

Frequently asked questions about Composer Installers Extender
How do I install custom package types (e.g., laravel-module) into app/Modules/ instead of vendor/?
Add `oomphinc/composer-installers-extender` to your project, then define the custom type in your root `composer.json` under `extra.installer-types`. For example, `"laravel-module": "app/Modules/%package%"` will install packages of type `laravel-module` into `app/Modules/`. Each custom package must declare its type in its own `composer.json` under `"type"`.
Will this work with Laravel’s package auto-discovery for custom-installed packages?
Yes, if your custom packages include a `PackageServiceProvider` and follow Laravel’s auto-discovery conventions. The extender doesn’t interfere with auto-discovery—it only handles directory placement. Ensure the package’s `composer.json` includes `"extra": { "laravel": { "providers": [...] } }` for auto-discovery to work.
Can I use this to install themes into resources/themes/ instead of vendor/?
Absolutely. Define a custom type like `"theme": "resources/themes/%package%"` in your root `composer.json`’s `extra.installer-types`. Themes must declare `"type": "theme"` in their own `composer.json`. This is commonly used for front-end themes or plugin-based designs.
What Laravel versions does this package support, and are there breaking changes?
This package works with Laravel 5.5+ and PHP 7.2+. There are no breaking changes, as it extends `composer/installers` without modifying Laravel’s core. However, for full modular support (e.g., auto-discovery), Laravel 8+ is recommended due to improved package handling.
How do I handle post-install tasks like symlinking or config publishing for custom packages?
Use Composer scripts in your custom package’s `composer.json`, such as `"post-install-cmd": ["php artisan vendor:publish --tag=config", "php artisan module:link %package%" ]`. The extender triggers these scripts automatically after installation, just like standard Composer packages.
Is there a risk of conflicts with existing composer/installers types (e.g., library, project)?
Low risk, but avoid reusing built-in types like `library` or `project`. The extender validates custom types against the default `composer/installers` types. If conflicts arise, use unique names like `laravel-module` or `app-plugin` and document them in your project’s `README`.
Can I use this with CI/CD pipelines (e.g., GitHub Actions) for testing custom packages?
Yes, the extender works seamlessly in CI. Test custom packages by installing them in a clean environment: `composer require vendor/package --dev`. For Laravel, run `php artisan config:clear` and `php artisan cache:clear` post-install to ensure no stale configurations interfere with testing.
What alternatives exist for custom package installation in Laravel?
Alternatives include `spatie/laravel-package-tools` (for package scaffolding) or writing a custom Composer plugin. However, this extender is lighter and avoids plugin complexity. For modular architectures, consider `illuminate/modules` or `spatie/laravel-module-stub`, but they require additional setup.
How do I ensure custom-installed packages don’t break Laravel’s service container?
Custom packages must register their service providers manually or via auto-discovery. If using auto-discovery, include a `PackageServiceProvider` and declare it in the package’s `composer.json`. For manual binding, publish config files and bind services in `config/app.php` or a custom config file.
Will this work with Composer 2.x, and are there performance benefits?
Yes, this package is fully compatible with Composer 2.x. Composer 2 offers performance improvements for large projects, especially when installing multiple custom packages. No additional configuration is needed—just update Composer globally or in your project’s `composer.json`.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
calmfox/watch-sylius
damienfern/grpc-symfony-bundle
atoolo/index-bundle
atoolo/genai-bundle
coprotoai/laravel-ticket
davidjln/llm-carbon-bundle
cryonighter/valid-request-bundle
coolms/taxonomy-bundle
coolms/field-bundle
articulate-orm/symfony
aaix/laravel-tall-architect
ephoto/akeneo-connector
emmanuelballery/eb-plantumlbundle
emielburgman/symfony-visitor-beacon
emielburgman/symfony-visit-storage
emielburgman/symfony-security-headers
emielburgman/symfony-log-viewer
emarref/xdebug-bundle
emarref/pubnub-bundle
elriseio/finance-money-bundle