- 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`.