Installer Laravel Package

Getting Started

The minimum viable setup for a Laravel project:

# Composer 2.x requires explicit opt-in for plugins
composer global require rikudou/installer

If you need it project-scoped (recommended for reproducibility in CI):

composer require --dev rikudou/installer

Then, in composer.json, allow the plugin to execute (Composer 2.2+ security default):

{
  "config": {
    "allow-plugins": {
      "rikudou/installer": true
    }
  }
}

Re-run composer install (or composer update <package>) so the plugin activates.

Where to look first: The repository README and the package's composer.json — the archive status means the documentation has not been maintained, so the source (typically src/Plugin.php and any Installer/ subfolder) is the authoritative reference. Grep the package for PluginInterface, EventSubscriberInterface, and event names (post-package-install, post-package-update) to see which lifecycle hooks it wires into and what install-rule files (commonly installer.yaml, rikudou.yaml, or similar in a package root) it looks for.

First use case: installing a third-party package that ships its own install manifest (e.g. config files to copy into config/, service providers to register, service aliases to add). When you composer require that package, the plugin fires after install and applies the manifest automatically — no manual copy/registration step.

If you are evaluating it for a new Laravel codebase: don't. Laravel 5.5+ already has package discovery via extra.laravel.providers and extra.laravel.aliases in a package's composer.json, and php artisan vendor:publish handles config/asset copying. This plugin is only worth considering if you have a legacy vendor that ships an installer manifest, or you maintain packages where you can't rely on Laravel's discovery.

Implementation Patterns

Legacy package provider registration. For an older package that requires manual provider registration in config/app.php, a manifest-based installer can add the provider entry automatically on post-package-install. Keep a hand-written backup of config/app.php in version control so you can diff what the plugin wrote.

Config file scaffolding. The typical pattern: your project requires a package, its manifest lists config_files: { 'publish/foo.php': 'config/foo.php' }, and the plugin copies the file only if the destination doesn't already exist (check the plugin source — behavior on existing files matters, especially for updates).

Wrapping it in a monorepo workflow. If you maintain multiple internal packages under packages/* with "type": "path", composer post-package-install events still fire, so the installer can scaffold each package's config into the host app during development. This is the most defensible use case in 2024/2025 — internal tooling where you control both sides.

Skipping install on specific packages. Look for an option like require's --no-scripts (scripts run before the plugin's hook, so this is coarse) or the plugin's own config key (commonly extra.rikudou.installer.ignore). Test on a throwaway project before relying on it.

Combining with your own post-install scripts. Since the plugin fires in the same event loop as composer scripts, avoid duplicating work. If you have post-install-cmd scripts that already run php artisan vendor:publish, disable the plugin's config-copy step for those packages or you'll get "file already exists" churn.

CI/CD integration. Because the package is archived, pin it by commit hash in composer.json ("rikudou/installer": "dev-main#abc1234") rather than a branch reference, and add config.allow-plugins to the repo's composer.json so CI doesn't accidentally block the plugin. Prefer a --no-plugins install in the dependencies stage of your pipeline and only allow the plugin in the build stage if you actually need it.

Using it with Docker builds. Composer plugins run during composer install inside the image. Ensure COMPOSER_ALLOW_PLUGINS=1 is set or the allow-plugins entry is present in the image's composer.json, otherwise the plugin silently won't run and you'll get packages that require the manifest but never applied it.

Gotchas and Tips

• Archived, zero dependents, WTFPL. No security patches, no support, no ecosystem to cross-reference. If it breaks with a future Composer release (it is a composer plugin, so major Composer upgrades are a real risk), you own the fix. Fork it, audit the diff, and vendor it as type: path rather than pulling from Packagist if it's load-bearing for your build.
• Composer 2.2+ allowlist. A silent failure mode: composer install succeeds, but the plugin never fires because it's not allowlisted. Check composer diagnose output — it warns about non-allowed plugins.
• Overlaps Laravel's built-in discovery. If a package declares extra.laravel.providers and ships a RikudouInstaller manifest, you may end up with the provider registered twice. Inspect bootstrap/providers.php (Laravel 11+) or config/app.php after install and remove the duplicate entry the plugin added.
• Diff after install. There's no dry-run mode documented in most installer plugins of this generation. Run git diff after every composer update that touched a manifest-carrying package. Commit the plugin's edits as a separate, reviewable commit so behavior changes are auditable.
• Config merge vs. overwrite. Test what happens on composer update of a package that already had its config published. If the plugin overwrites, that's data loss — always back up config/*.php and config/app.php before updates in a package that uses this plugin.
• Extension point. If a manifest file needs to be authored for an internal package, the file format is defined entirely by the plugin's parser. Read the parser once, write a minimal manifest, and add a tests/ fixture that asserts the post-install output. That test is the only thing standing between you and a silent regression when Composer bumps its plugin API.
• Debugging. composer install -vvv shows plugin event dispatch. If a manifest is being ignored, check: (a) the manifest filename and path root, (b) the package's type field (usually must not be metapackage), (c) whether the manifest references paths that don't exist in the installed package — most naive parsers fail silently on missing source files.
• Prefer the replacement. For anything you control, replace this plugin's role with: package discovery (extra.laravel), vendor:publish for config assets, and a post-create-project-cmd script for the rest. The plugin is only worth keeping for the specific case of a vendor package whose manifest you can't rewrite — and even then, patching that vendor package via composer patch (cweagans/composer-patches) or a private fork is usually the lower-risk option.