Installer Laravel Package

Technical Evaluation

What it is: rikudou/installer is a Composer plugin that hooks Composer's install/update lifecycle to apply package-provided configuration automatically — conceptually a lightweight, framework-agnostic analogue to Symfony Flex recipes. The value proposition is that a package author can ship an "install recipe" so consumers get config files, service registrations, or scaffolding written into their project without a manual vendor:publish + edit ritual.

Architecture fit. The problem fits Laravel well: Laravel's package auto-discovery covers service providers and aliases, but stops short of config publishing, .env keys, migration ordering, or asset scaffolding — teams still run php artisan vendor:publish --tag=... and hand-edit. A recipe layer is a genuine gap. The implementation fits less cleanly:

• Composer plugins execute with the installing user's privileges at dependency-resolution time. Since Composer 2.2, plugins must be explicitly allowlisted via config.allow-plugins, so adoption is an org-wide supply-chain policy change, not a composer require.
• The plugin is framework-agnostic, not Laravel-aware. It overlaps rather than integrates with Laravel's package:discover and vendor:publish conventions, so you'd be running two parallel configuration-bootstrap mechanisms.
• The opportunity: 4.65 against a score: 0.03 is the defining signal: a validated problem with an unvalidated, unmaintained solution. Treat the space as interesting and this artifact as a design reference, not a dependency.

Integration feasibility. Mechanically low-effort — it's a Composer plugin, installable globally or per-project, with no runtime footprint in the application. That is its one real strength: an install-time-only tool cannot introduce production runtime attack surface or request-path latency. The blocker is evidentiary, not mechanical: 0 stars, 0 dependents, and an archived repository mean there is no field validation, no compatibility matrix, and no observable behavior on modern PHP or Composer 2.7.x.

Technical risk (ranked):

1. Abandonment. Archived = no PHP 8.3/8.4 support, no Composer 2.x plugin-API tracking. Composer's plugin events (post-install-cmd, post-package-install, pre-package-uninstall) have shifted across 2.x; an unmaintained plugin is a latent CI break on the next Composer bump.
2. Arbitrary code execution at install time. Recipes that write to the project tree are, by design, an unconstrained file-mutation channel. There is no sandboxing, dry-run, or diff-review contract documented. In a CI or deploy pipeline this is a non-starter without an internal review gate.
3. License. WTFPL is maximally permissive and imposes no conditions — convenient for an internal fork (you may relicense) — but carries no warranty, no patent grant, and no indemnification. Legal will flag it less for copyleft than for the absence of any IP assurance, which matters if the recipe mechanism becomes load-bearing.
4. Silent no-op failure. If allow-plugins isn't configured, Composer warns and proceeds; recipes simply never apply. Teams will believe configuration is automated when it isn't.
5. Idempotency is unproven. The description does not state whether repeated installs are safe. Non-idempotent file mutation on a shared repo is a merge-conflict generator.

Key questions before any decision:

• What is the recipe format — declarative (YAML/JSON diff) or executable PHP? This single answer changes the risk tier from "manageable" to "code review per package."
• Are recipe applications idempotent, and is there a dry-run/--no-scripts-style escape hatch?
• What Composer and PHP versions does the last commit target?
• Does it support uninstall/revert, or is state one-way?
• Which event does it hook, and does it run on composer install in CI (i.e., every build) or only on first require?
• Is there any prior art in the repo's issues that indicates use outside the author's own projects?

Integration Approach

Stack fit. Neutral-to-poor as a direct dependency, good as a pattern reference. Our stack is Composer 2.x + Laravel 10/11 with a mix of in-house and third-party packages. The plugin's install-time-only lifecycle actually sidesteps the usual Laravel compatibility matrix (no service provider, no facade, no published config schema to version), which is the one thing that de-risks it. But it duplicates a responsibility Laravel already owns, and dual ownership of "how packages configure themselves" is an architecture smell.

Compatibility. Unverified. No published constraint set, no CI matrix, no dependents to infer from. Assume Composer 1-era plugin semantics until proven otherwise; test explicitly against the pinned Composer version in our build images.

Migration path. There is nothing to migrate from — this is additive tooling. The realistic paths are:

• Adopt-as-is: rejected. Archived, unvalidated, install-time code execution, no security response channel.
• Internal fork (recommended if the pattern is pursued): WTFPL permits this cleanly. Fork, pin to a tagged internal version, add a PHPUnit suite, add a --dry-run and an idempotency contract, gate recipe application behind an explicit opt-in in composer.json, and publish to a private registry. Budget ~2–3 engineer-weeks for hardening plus ongoing ownership.
• Build the thin slice ourselves: a ~200-line Composer plugin applying declarative YAML recipes is a well-bounded problem. This is likely cheaper than rehabilitating an abandoned codebase and gives us a reviewable diff surface.
• Do nothing / status quo: vendor:publish --tag plus documented setup steps. Zero risk, known friction. Legitimate if package-configuration churn is low.

Sequencing:

1. Inventory: how many internal packages currently require manual post-install steps? If the answer is fewer than ~5, the problem doesn't justify the tooling — close the ticket.
2. Sandbox PoC in a throwaway repo against our pinned Composer/PHP versions. Timebox: 2 days. Output is a written verdict on recipe-format safety and idempotency.
3. Decide adopt-fork vs. build-thin vs. status quo on PoC evidence.
4. If proceeding: legal sign-off on the fork's licensing posture, allow-plugins policy amendment, CI job covering the plugin path, and a documented bypass for --no-plugins production installs.
5. Pilot on exactly one low-blast-radius internal package before any org-wide rollout.

Operational Impact

Maintenance. Effectively infinite, because it starts at zero. An archived repo with no maintainer means the fork owner is the maintainer from day one. Ongoing cost is not bug-fixing (the codebase is small and stable-by-abandonment) but compatibility chasing: every Composer major and minor that touches the plugin API, every PHP minor that trips a deprecation, and every new recipe feature our teams request. Estimate 1–2 engineer-days per Composer/PHP upgrade cycle plus feature requests — modest but permanent, and it lands on whoever owns internal developer tooling.

Support. None externally. No issue triage, no security advisories, no CVE response. Internal support means an on-call rotation or a named owner for a tool that sits in the critical path of every developer's composer install. That is a disproportionate support burden for the value delivered. Note the flip side: zero dependents means zero inherited vulnerability surface — the supply-chain risk is the plugin itself, not its transitive tree.

Scaling. Install-time execution scales acceptably in wall-clock terms (recipes are file writes, not network calls), but it scales badly in organizational terms:

• Every developer machine and every CI job runs the plugin on every composer install. A non-idempotent recipe means repeated rewrites of tracked files → dirty working trees → spurious review noise.
• Composer's cache and --no-plugins production installs become divergent code paths: the feature is present in dev and absent in prod builds. Any config the recipe generates must therefore be committed, which partly defeats the automation rationale.
• Recipe drift across dozens of packages is unversioned behavior — there's no lockfile entry describing which recipes ran, so reproducing a teammate's exact project state becomes guesswork.

Failure modes. Enumerate these for the runbook: (a) silent no-op when allow-plugins is unset — most likely and most dangerous; (b) Composer upgrade breaks the plugin and halts installs org-wide, since a throwing plugin fails the install; (c) recipe applies a partial file mutation on interrupt, leaving a half-written config that passes syntax checks but is semantically wrong; (d) conflicting writes between two packages targeting the same config file; (e) path handling on Windows dev machines; (f) recipe re-application overwriting local developer edits. Modes (a), (b), and (f) are the ones that will actually page someone.

Ramp-up. Low for consumers (install, allowlist, done), high for owners. Understanding Composer's plugin event model, the allow-plugins trust mechanism, and idempotent file-mutation design is specialized knowledge that few Laravel developers carry — the ecosystem's convention is service providers and publish tags, not install-time mutation. Expect a half-day of onboarding for each engineer who has to debug a failed install, and a dedicated owner who can read Composer's internals. Documentation will be entirely ours to write; the upstream repo provides none we can rely on.

Verdict. Adopt the pattern, reject the package. The 4.65 opportunity score reflects a real gap in Laravel's package-configuration story; the 0.03 package score and archived status reflect that this specific artifact is a design sketch, not a dependency. Recommend either an internally owned thin implementation or a documented status quo, and revisit only if package-configuration toil proves to be a measured, recurring cost.