Composer Patches Plugin Laravel Package

Product Decisions This Supports

• Ship-now vs. wait-for-upstream. Lets the team decide to carry a targeted fix on top of an unpatched dependency instead of blocking a release on a vendor's roadmap. The PM decision becomes "do we accept a patch we now own?" rather than "do we delay the launch?"
• Build vs. buy vs. fork. Positions patching as the cheap middle path: cheaper than maintaining a full fork or vendoring a private copy, but with a real ongoing ownership cost that must be resourced (patch review, drift checks on every dependency bump).
• Security and compliance response time. Supports a defensible answer to "how fast can you remediate a CVE in a third-party package where no fixed release exists?" — an SLA question that shows up in enterprise deals and security questionnaires.
• Technical-debt and roadmap sequencing. Makes visible how much of the delivery timeline depends on upstream behavior, which informs whether to invest in upgrading, isolate the dependency behind an adapter, or replace it.
• Ecosystem fit decisions. Most relevant where the product is Laravel/PHP and already uses Composer-driven builds; the pattern (declarative patches applied at install time) matters most in Drupal/Symfony/Laravel stacks where patching third-party modules is a normalized practice.
• Release engineering investment. Choosing this package is a decision to treat patching as first-class infrastructure — patch files in the repo, applied automatically in CI — versus ad-hoc edits to vendor/ that no one can reproduce.

When to Consider This Package

Consider it when most of the following hold:

• You have at least one dependency that needs a fix, and no acceptable upstream release or backport timeline.
• The fix is small and well-scoped (a one- or two-hunk change), not a feature or an architectural divergence.
• You can commit to patch hygiene: patch files in version control, a named owner, and a review on every dependency upgrade.
• Your build is Composer-based and reproducible in CI, and you want patches applied automatically rather than via a documented manual step.
• Legal is comfortable with AGPL-3.0 tooling in the dev/build chain. As a dev-time Composer plugin it is not distributed with your product, so this is usually acceptable — but AGPL is a strong copyleft license and it should be a recorded, explicit sign-off, not an assumption.
• You are willing to pin the plugin version and accept a small-project risk profile.

Look elsewhere — or solve it differently — when:

• The upstream fix is days away. Waiting is cheaper than owning a patch.
• The change is large or contentious. Fork or vendor the package under your own namespace with a VCS repository entry; patches stop scaling past a handful of hunks.
• There is a more established incumbent in your stack. cweagans/composer-patches is the widely adopted option with far more deployment history; at ~80 stars and an unreported repository, this package's adoption and bus-factor signals are thin. Prefer the incumbent unless you have a specific reason — and if you can't state that reason, that's the answer.
• You need vendor support or a maintenance guarantee. Neither is available here; this is a community tool.
• Your org forbids strong-copyleft licenses outright, even for build tooling. Pick a permissively licensed alternative instead of fighting the policy.
• Your team cannot sustain patch review. Every skipped review is a silent divergence that resurfaces as a production bug months later.

Practical note: whatever you pick, require the patch set to be small, documented with an upstream issue link, and reverted the moment a real release lands. A patch with no ticket is a bug you scheduled for later.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost piece of build tooling that removes a common cause of schedule slip — waiting on a third party to fix a bug we didn't cause. It lets us keep a release date and carry a narrowly scoped, tracked fix instead of delaying the roadmap or paying for a full fork. The trade is modest and bounded: we take on ownership of a few lines until the upstream release lands, and we must track and retire them. Cost is engineer time, not license or infrastructure spend. Two caveats worth your awareness: the license is AGPL-3.0, which is acceptable for build-time tooling but should get a quick legal confirmation, and the project is small and lightly adopted, so we pin the version and keep an exit path. Recommendation: approve for a trial on one release, with a hard requirement that every patch is documented and tied to an upstream ticket.

For engineering: This gives you a declarative, repeatable way to apply patches to Composer dependencies during install — no more hand-editing vendor/, no more "it works on my machine." Patches live in the repo, are reviewed like code, and apply identically in CI and local dev. That means reproducible builds, an auditable record of every divergence from upstream, and a clean removal path once a fixed release ships. Non-negotiables if we adopt: one patch directory with a README mapping each patch to its upstream issue, a reviewer on every patch, a check on dependency upgrades that fails loudly when a patch no longer applies, and a pinned plugin version. Before committing, benchmark it head-to-head against cweagans/composer-patches — we should be able to articulate why we'd take the less-adopted tool, and "the incumbent didn't work for us" is the only good answer. Also note the license is AGPL-3.0: it stays out of runtime dependencies and out of anything we distribute, so it's confined to the build chain, but treat that as a constraint to keep, not a detail to forget.