Conflicts Laravel Package

Product Decisions This Supports

• Upgrade roadmap and release sequencing. The conflict set is effectively the compatibility boundary for a Shopware version. It tells you which extension versions must be deprecated, upgraded, or dropped before you can promote a minor release — useful input for gating an upgrade behind ecosystem readiness rather than a calendar date.
• Extension ecosystem governance. Decide whether compatibility is enforced by machine-readable metadata or by documentation, QA, and merchant goodwill. This package is the machine-readable option, and adopting it is a policy decision as much as a technical one.
• Support-cost reduction. Every conflict entry converts a class of "site broke after install/update" tickets into a Composer error at build time. That is a straightforward trade of a few minutes of developer friction against merchant-facing incidents.
• Build vs. buy for a compatibility matrix. Maintained upstream, this is a dependency you consume; the alternative is curating your own blocklist, which decays the moment nobody owns it. Adopt upstream, and reserve forking for private or agency-specific extensions.
• Distribution and template strategy. If you ship a Shopware distribution, agency boilerplate, or merchant starter kit, including it sets a default safety posture for every project downstream at near-zero marginal cost.
• Partner communication. Conflict entries give you a concrete, dated artifact to point extension vendors at when negotiating deprecation windows and remediation SLAs.

When to Consider This Package

Consider it when:

• You operate Shopware 6 with third-party extensions, especially across multiple merchants or versions.
• You maintain a distribution, template, or CI pipeline where install-time enforcement is cheaper than runtime detection.
• You are planning a minor-version upgrade and want the ecosystem's known incompatibilities expressed as a build failure rather than a checklist.
• You want a single, shared source of truth instead of each team's hand-maintained list.

Look elsewhere or handle with care when:

• You are not on Shopware 6 — the value is entirely ecosystem-specific.
• You need a full compatibility matrix (every extension × every version, pass and fail). This package only hard-blocks known-bad combinations; absence of a conflict is not a guarantee of support.
• You need runtime capability detection, feature flags, or graceful degradation. Composer conflicts are install-time only and do nothing for an already-deployed merchant.
• You depend on private or in-house extensions with custom constraints — you will need a local override, which means owning a policy for it.
• Verification caveat: the repository metadata here is unknown and the star count is low, which is normal for infrastructure packages but means you must confirm release cadence tracks Shopware minor releases, that entries are reviewed rather than appended blindly, and that a stale upstream list does not silently become your compatibility ceiling. A blocking dependency you do not control can fail builds for reasons outside your release process, so define an override and pinning policy before rollout.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost dependency that moves extension incompatibility from "merchant discovers it in production" to "the build refuses to install it." It reduces upgrade risk and support load across the merchant base, requires no application code, and adds no runtime overhead. The only real commitment is governance: someone must track upstream releases alongside Shopware releases and own the exception process.

For engineering: It is a Composer conflict declaration set — declarative, transitive, deterministic, and CI-friendly. It fails fast and locally, before deployment, and composes cleanly with existing lockfile and pipeline discipline. No services, no migrations, no API surface. The integration work is a line in the distribution's composer.json, plus a documented override path for the cases where the upstream list is stricter than your own tested reality.

Ask: approve inclusion in the standard distribution and name an owner for the version-tracking and override policy.