Composer Dropin Installer Laravel Package

Product Decisions This Supports

• Feature scoping for deployment & upgrades. Enables a product to ship "drop-in" files (WordPress advanced-cache.php, object-cache.php, db.php, sunrise.php; Drupal settings.local.php-style overrides; platform-specific config files) into arbitrary application paths as part of a Composer install — without writing bespoke post-install scripts.
• Build vs. buy. Replaces a custom post-install-cmd/post-update-cmd copy routine (or a shell script in CI) with declarative rules in composer.json. That is usually 1–2 engineering days saved per ecosystem and removes a class of "forgot to copy the file" production bugs.
• Safe-upgrade policy. The package's core value — install without overwriting existing files — directly supports a product decision to protect customer customizations across upgrades. That maps to fewer support tickets and lower upgrade-risk metrics.
• Extensibility roadmap. Lets a product offer "bring your own drop-in" — customer-contributed cache configs, custom db.php routers, per-tenant overrides — while keeping the base install reproducible from a lockfile.
• Use cases worth evaluating. WordPress/Drupal-based SaaS or agency deployments; multi-site fleets where drop-ins must be versioned; products that vendor a CMS and want to keep drop-in management inside Composer; internal "starter kit" distributions that need to place files in known locations.

When to Consider This Package

Adopt when all of these hold:

• Your app relies on a platform convention that expects files at specific paths outside vendor/ (WordPress, Drupal, or a similar drop-in pattern).
• You want those files versioned and installed via Composer, not hand-copied.
• Non-overwrite semantics are a requirement — users or tenants edit the file and upgrades must not clobber them.
• Your team already tolerates Composer installer plugins in the dependency graph.
• The specific drop-in set is small and stable enough that a low-adoption dependency is acceptable.

Look elsewhere when:

• You are Laravel-native and don't ship files into arbitrary platform paths — use vendor:publish + service providers instead.
• You need file merging/patching, not just "copy if absent" — this package won't merge.
• Your org prohibits custom Composer installer plugins for supply-chain/security reasons.
• You need enterprise-grade maintenance signals (48 stars, 0 dependents, WTFPL) — this is a "small utility, vendor it if critical" package, not a foundation.
• A generic composer.json script block with rsync/cp -n would do the same job with fewer moving parts.

How to Pitch It (Stakeholders)

For executives (1-minute read). We can remove a hand-maintained copy step from our deployments by adding a small Composer plugin that places platform drop-in files on install and never overwrites files customers have customized. Effect: fewer upgrade incidents, less custom glue code to own, no license cost (WTFPL). Trade-off: it's a niche package with limited community adoption, so we'd pin a version and keep an internal fork/fork path if it becomes load-bearing. Recommended next step: a one-sprint spike on one deployment lane to measure incident reduction before wider rollout.

For engineering. Declarative alternative to post-install-cmd scripts: define target paths for packages or individual files in composer.json, and the installer skips files that already exist. Safe-by-default behavior matches upgrade semantics we want. Risks to price in: low maintainer surface, no active dependents to lean on for battle-testing, WTFPL means we own support. Mitigation: pin the version in composer.lock, add a smoke test that asserts the drop-in set lands in the right place, and keep a vendored copy of the plugin in our repo.