Ext Swoole Laravel Package

Product Decisions This Supports

• Runtime strategy: Swoole vs. OpenSwoole vs. both. The package's stated job is to make ext-swoole satisfiable by ext-openswoole at the Composer level. That turns "which async extension do our users run?" from a packaging constraint into a free variable — you can ship one artifact and let the host decide.
• Build vs. buy (the real decision here). The capability appears to be a thin Composer provide declaration plus guard code, not a polyfill. So the honest framing is "take a one-maintainer dependency" vs. "inline a few lines we own forever." For most teams the second option wins; this package is best treated as a reference implementation or a temporary bridge.
• Roadmap and vendor-risk hedging. Swoole and OpenSwoole have separate governance and diverging commercial interests. Supporting both keeps a migration path open without forcing a breaking Composer change on downstream users — useful if you want optionality before you need it.
• Use cases that actually apply: first-party PHP libraries that hook coroutines/server lifecycle and want one requirement string; internal base images or PaaS that ship whichever extension the distro packages; trimming a CI matrix; avoiding --ignore-platform-req as a de facto support policy in customer install docs.
• Where it does not move the needle: application teams on Laravel. Octane already abstracts the driver, so this is a package-maintainer and platform-team tool, not an app-level one.

When to Consider This Package

Adopt when:

• You maintain a library that genuinely works on both extensions and are tired of dual branches or telling users to bypass platform requirements.
• You must install into environments where only OpenSwoole is available (distro packages, managed hosts, customer infrastructure).
• You already test both runtimes and want the Composer metadata to reflect reality.

Look elsewhere or skip when:

• You depend on APIs that diverge between the two (coroutine DB clients, hooks, version-gated functions). The shim declares interchangeability; it does not polyfill classes or normalize behavior. Divergence remains your bug to find.
• Your IDE/PHPStan setup needs extension stubs — you'll maintain both stub sets regardless.
• You need Swoole-specific commercial/Plus features.
• Ecosystem signals matter to your risk model: 1 star, 0 dependents, single maintainer, no downstream validation. Not disqualifying for a shim this small, but it means you absorb the bus factor — pin it, vendor it, and add a CI smoke test that asserts the extension actually present matches what you expect.
• You're an app team; the abstraction already exists upstream.

How to Pitch It (Stakeholders)

Executives: "A small dependency that removes a forced choice. Today, if a customer's server has OpenSwoole instead of Swoole, our package refuses to install — that's a support ticket and a stalled deployment. This makes our requirement accept either, at near-zero engineering cost. The tradeoff is maturity: it's a single-maintainer package with no adoption, so we'd pin the version and be prepared to inline a few lines ourselves. Low cost, low risk, modest upside."

Engineering: "It's a Composer-level provide so ext-swoole is satisfied by ext-openswoole. No polyfills, no API normalization, no runtime behavior change. If we adopt it, two obligations follow: (1) CI must exercise both extensions, and (2) any divergent call path needs an explicit guard. Given the bus factor and Apache-2.0 licensing, my recommendation is to fork or vendor it rather than depend on it directly — the code surface is small enough that we'd own it cheaply."