Composer Dropin Installer Laravel Package

Technical Evaluation

Architecture fit. koodimonni/composer-dropin-installer is a Composer installer plugin, not an application library. It hooks Composer's install/update lifecycle and, for packages that declare a dropin-paths map in their own extra block, copies selected files into project-relative paths only when the destination does not already exist. Architecturally this is a narrow, well-understood seam: it changes where vendor artifacts land and changes the overwrite policy from "replace" to "write-once." That fits a specific shape of project — a PHP application (typically WordPress/Bedrock-style) that needs vendor-supplied drop-ins (object-cache.php, advanced-cache.php, mu-plugins, custom config stubs) placed in the web root without stomping on site-owner customizations. It does not fit general dependency management, and it is not a substitute for composer/installers unless the write-once semantics are the actual requirement.

Integration feasibility. Mechanically easy: add the plugin, composer install, done. The friction is almost entirely in (a) version compatibility and (b) governance. On compatibility, the plugin was written against the Composer 1 plugin API (composer-plugin-api ^1.0), and Composer 2 changed the PluginInterface surface and, from 2.2, gates all plugins behind an explicit allow-plugins allowlist. Expect it to require a fork or a maintained drop-in replacement unless the upstream has been updated; this is the single largest feasibility unknown and should be validated before any commitment. On governance, the WTFPL license is permissive but is a non-standard, legally ambiguous text that many enterprise OSS review boards will reject or flag; that is a procurement problem, not a technical one, and it needs to be resolved early because it determines whether a fork is even an option.

Technical risk. Ranked:

• Abandonment / bus factor. 48 stars, effectively zero dependents, no evidence of an active maintainer. You are adopting a plugin you may have to own. This is the dominant risk; everything else is downstream of it.
• Composer 2 / PHP 8 incompatibility. Blocks modern stacks; the fix is small but the fix is a fork, which converts a dependency into an owned asset.
• Silent no-op semantics. "Don't overwrite" means no error when a file exists. Required drop-ins can be absent or stale and Composer will exit 0. This is the most dangerous runtime failure mode and it needs compensating controls, not just documentation.
• Stale-on-upgrade. Because existing files are never replaced, upgrading the vendor package does not refresh a previously installed drop-in. Drift accumulates silently across environments.
• Supply-chain surface. The install target path is declared by the package, not the consumer. Any package using this installer can direct writes to project-relative paths, so the plugin widens the trust boundary of composer install and must be governed by the allow-plugins allowlist plus review of package extra blocks.
• License review. WTFPL may fail policy.

Key questions to resolve before design freeze.

1. Does a maintained fork or drop-in replacement exist that supports Composer 2.x and current PHP? If not, who owns the patch and for how long?
2. Is write-once the real requirement, or is the actual need "install to a non-standard path" (solvable with composer/installers + installer-paths) or "preserve local overrides" (solvable with a deploy-time template step)?
3. Which drop-ins are genuinely required at runtime, and which are nice-to-have? Required ones need an explicit post-install presence assertion.
4. Will OSS/legal accept WTFPL, or must the code be vendored under a different license with an internal owner?
5. How are existing deployments repaired when a drop-in is stale or missing — is there an idempotent refresh command, or is it a manual runbook step?

Integration Approach

Stack fit. Good fit when all of the following hold: PHP monolith with Composer-managed vendors; WordPress or WordPress-like layout with a committed web root; a small, stable set of drop-in artifacts; and a team willing to own a plugin fork. Poor fit for polyglot build systems, container images built from a lockfile where the web root is ephemeral (write-once semantics are meaningless if the filesystem is rebuilt every deploy), or any environment where two packages could target the same path. In a container-first stack, the correct integration is often "let the file be overwritten in the image, apply site overrides at deploy," which sidesteps this plugin entirely.

Migration path. Treat it as an adoption, not a refactor:

1. Spike in one non-critical repo. Pin an exact version, install on the current Composer version, and empirically confirm the plugin loads. If on Composer 2, expect to fork immediately and bump composer-plugin-api plus the PluginInterface method signatures.
2. Establish the fork before broad rollout. Create an internal fork under the org, tag it, publish to a private Composer repository or a VCS entry, and make the fork the pinned dependency everywhere. Do not pin upstream and plan to fork "later."
3. Move one drop-in at a time. Migrate lowest-risk artifacts first (mu-plugins, then cache drop-ins, then anything on the critical request path), verifying each parity-equivalent against the current manual or scripted placement.
4. Delete the old placement mechanism in the same change. Dual paths are how you get "which copy is live" incidents.

Compatibility. Three axes to verify per environment: Composer major version and plugin API constraint; allow-plugins entries in composer.json (required from Composer 2.2 onward, and a hard blocker in CI if omitted); and PHP version against the plugin's own constraints. Also confirm behavior on composer install --no-dev, on composer update, and inside CI caches that restore vendor/ without re-running installers — a restored vendor/ can present as "installed" with the install hook never having fired.

Sequencing. Compatibility validation → fork and publish → allowlist and policy sign-off → pilot repo → shared template/base composer.json → fleet rollout. Keep the fork and the pin in the same PR series so the org never runs upstream and fork in parallel.

Operational Impact

Maintenance. Budget for steady-state ownership, not just adoption. Realistic recurring work: tracking Composer plugin-API changes (which have broken plugins before and will again), PHP minor-version compatibility, and rebasing the fork if upstream ever moves. Even if the fork is a three-line signature change today, it is a permanently held package with no upstream to defer to. Assign a named owner and a review cadence; an unowned fork is worse than an unmaintained dependency because it looks supported.

Support. There is no meaningful community to escalate to — small star count, no dependents, no visible maintainer responsiveness. Internal L1/L2 runbooks must cover: drop-in missing, drop-in stale, drop-in installed to the wrong path, and "Composer says success but the file isn't there." Document the exact glob/path expansion for each package so support can trace a target path without reading installer source.

Scaling. Throughput is a non-issue: operations are local filesystem copies of a handful of files per install, with negligible time and no network calls. Scaling concerns are organizational rather than computational — the number of packages declaring dropin-paths and the number of environments where those paths must stay consistent. Growth in either dimension increases the chance of two packages targeting the same destination, which the plugin will resolve by "first write wins" rather than by conflict error. Cap and review the set of packages permitted to use this installer.

Failure modes.

• Silent skip. Destination exists → no write, no warning, exit 0. A missing required drop-in surfaces as a runtime fatal or a silently disabled feature (e.g., no object cache) rather than a build failure. Mitigation: a post-install assertion step in CI and in the deploy pipeline that verifies presence and expected content hash for required drop-ins.
• Stale artifact drift. Vendor upgrade does not refresh an existing drop-in, so environments diverge by install history. Mitigation: define a documented refresh procedure (delete-then-install) and a drift check that compares live files against the version expected by the lockfile.
• CI cache masking. vendor/ restored from cache skips the installer entirely. Mitigation: key caches on composer.lock and force a cold install on release builds.
• Path resolution surprises. Glob patterns in package extra resolve relative to the Composer working directory; running Composer from a subdirectory can place files unexpectedly. Mitigation: enforce a single canonical install root.
• Plugin gate. A missing allow-plugins entry causes a hard failure on Composer 2.2+, or an interactive prompt that hangs unattended CI. Mitigation: commit the allowlist and run non-interactive in CI.

Ramp-up. Low individual learning curve for a PHP developer — an hour to understand the installer type, extra schema, and write-once behavior. The real ramp-up is organizational: teaching the team that "installed" does not mean "current," and that a green Composer run is not evidence the drop-in is in place. Plan for a short internal write-up, a shared post-install verification script, and one brown-bag session before the second team adopts it.