Compress Contracts Laravel Package

Product Decisions This Supports

• Feature framing: "pluggable compression" as a seam, not a feature. wyrihaximus/compress-contracts is a marker interface (no methods), so its only product value is as a shared type token: it lets our code ask "is this object a compressor?" without binding to a concrete implementation. That is an architectural decision, not a user-facing one. Adopt it only if the roadmap actually contains two or more compressor implementations or an extension point where third parties inject one.
• Build vs. buy vs. borrow. Build cost is near zero (a single interface, MIT licensed, copyable in an afternoon). "Buy" cost is also near zero. The real decision is vendor risk vs. shared-vocabulary benefit: this package earns its place only if it becomes a common name across our packages and the ecosystem's, which is a network effect we do not control (currently 0 dependents, 2 stars).
• Roadmap gating. Treat this as a dependency of a dependency story: relevant if we adopt a broader ReactPHP/async compression stack from the same maintainer (wyrihaximus/compress family). As a standalone item it does not unlock a roadmap milestone by itself.
• Use cases that justify it. (a) A plugin/extension contract so integrators can supply their own compressor without us shipping a hard dependency; (b) a discriminator in DI/container wiring or in a factory that must branch on capability; (c) a stable, SemVer-safe boundary so our internal compressor implementations can be swapped without consumer churn.
• Use cases that do not justify it. Internal-only compression where we control every call site. Here a private interface in our own namespace gives identical type safety with zero external dependency, zero license/notice obligations, and no upgrade coupling.
• Exit cost is genuinely low. Marker interfaces almost never change shape, so churn risk is minimal; if the package is abandoned, forking is a copy-paste. This asymmetry (low risk, low reward) is the core of the decision.

When to Consider This Package

Adopt when all of these hold:

• You are already inside the WyriHaximus async package family, or you are explicitly standardizing on its contracts, so the shared name has real interop value.
• You need a public extension point (third-party or cross-team compressors), where "use the ecosystem's interface" beats "use ours."
• You want to keep a consumer package free of any concrete compression dependency (contract-only require).
• You accept the maintenance reality: last release 2020-12-24, 2 stars, 0 dependents. Pin it, and budget a plan for vendoring if PHP-version constraints ever bite.

Look elsewhere (or inline it) when any of these hold:

• You are not in that ecosystem. With 0 dependents and a 2020 release, you get no network benefit, only an external dependency. Define interface Compress {} in your own package.
• You need behavior, not identity. A marker interface declares no methods, so it cannot define a compression API. If you need compress(): string / decompress(), this package solves nothing; look at concrete implementations such as wyrihaximus/compress or PSR-style abstractions.
• Your org requires active maintenance, security response SLAs, or a named maintainer. A 5-year-old 2-star package will not clear that bar; fork or reimplement.
• Licensing hygiene matters for redistribution. MIT is permissive and low-friction, but it still creates a notice obligation and one more entry in your SBOM for a 100-character interface; weigh that against the benefit.
• PHP version support is a blocker. Verify composer.json constraints against your runtime before committing; validate rather than assume, since documentation here is essentially the description line.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a free, MIT-licensed, single-interface PHP package that acts as a shared label for "this thing compresses." It is not a feature; it is a naming convention that lets different parts of our code and third-party extensions agree on terminology. Cost is effectively zero and so is standalone value. Recommendation: do not adopt as a standalone initiative. Fold it into a decision only if we commit to a broader pluggable-compression architecture, where it becomes the cheap, low-risk contract layer.

For engineering (60 seconds): wyrihaximus/compress-contracts defines a method-less marker interface, so it enforces identity, never behavior. That means it can gate capability checks and DI wiring but cannot standardize a compression API. It is a 2020 release with 0 dependents and 2 stars, so we should treat it as frozen but stable: expect no churn, get no support, and pin the version. If we are already in the maintainer's async ecosystem, take it for interop. If not, write the interface in our own namespace, keep the dependency graph and SBOM clean, and revisit only if we need ecosystem interop.

Ask: Confirm whether pluggable compression with external implementers is on the roadmap this year. If yes, prototype with the contract and validate PHP constraint compatibility in the same spike. If no, decline and record the rationale so the same 30-minute evaluation is not repeated next quarter.