Curl Wrapper Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package. Its integration surface is Symfony\Component\HttpKernel\Bundle\Bundle plus a DI extension that loads service definitions. Laravel has no bundle registration, no config/bundles.php, and no container extension semantics — PSR-11 interop gets you a container, not a bundle loader.
• Release 1.0.6 confirms this: the entire change is a fix to Symfony\Component\DependencyInjection\Alias::setPrivate() → setPublic(). That is a fix to the DI extension layer — precisely the layer we would delete on day one. The release tells us where the maintainer's attention is, and it is not on the HTTP client.
• The actual reusable asset remains a single curl wrapper class (a thin OOP facade over ext-curl). Everything else in the repo is Symfony scaffolding we would delete.
• Net: the value proposition for a Laravel codebase is still a ~one-class abstraction we could write ourselves in an afternoon, delivered inside a framework integration we cannot use. 1.0.6 does not change this ratio; it slightly increases the amount of Symfony-specific code we'd be discarding.

Integration feasibility

• Feasible only in the "extract the class" sense: identify the client class, copy or fork it, autoload via PSR-4 in our app, bind to an interface in a ServiceProvider. Budget half a day for the spike, one to two days for a productionized adapter with tests.
• Composer resolution is still the first blocker. The 1.0.6 note references symfony/dependency-injection 5.2 deprecations, which implies the maintainer is now developing against Symfony ≥ 5.2 — but the release note does not state whether composer.json constraints moved. A constraint bump here could newly pull Symfony 5.4/6 components that conflict with what Laravel 10/11 already resolve. We cannot assume the dependency picture is unchanged; re-read composer.json before anything else.
• If it hard-depends on symfony/framework-bundle at runtime (not just require-dev), extraction is mandatory, not optional. 1.0.6 gives no evidence either way.

Technical risk

• Abandonment — revised, still high: 1.0.6 is the first release since 2021-04-27, and it is a one-line deprecation fix in the Symfony DI layer, not an HTTP-layer fix. This is evidence of occasional maintenance, not a cadence. Still 2 stars, 0 dependents, single maintainer, no security policy, no published CI signal, effectively no external review. Every defect in the HTTP path remains ours.
• Correctness risk in the one thing it does: unchanged and unaddressed by this release. curl wrappers are where TLS verification gets silently disabled (CURLOPT_SSL_VERIFYPEER => false), where timeouts are omitted so workers hang, and where curl_exec returns false instead of throwing. These are exactly the failure modes that don't show up until production traffic. 1.0.6 touches none of them.
• PHP 8.x drift: unchanged, possibly marginally improved if the release also touched other deprecations — but the note scopes to DI only. Treat 2021-era code patterns (null to non-nullable internal params, curl_close no-ops) as still present.
• New minor risk — DI visibility semantics: switching an alias from private to public in Symfony changes container visibility semantics and can alter lazy/inlined service behavior. Irrelevant to us because we never load the container, but it means the release is a behavioral change for existing Symfony consumers, not a pure no-op. Reinforces "extract, don't require."
• Opportunity cost: unchanged. Laravel ships Illuminate\Support\Facades\Http (Guzzle) with fakes, retries, middleware, pooling, and ->withOptions(['curl' => ...]) escape hatches.

Key questions

1. Did 1.0.6 change composer.json constraints (php, symfony/*) alongside the DI fix — and does symfony/framework-bundle remain a runtime requirement?
2. Is there a changelog or diff beyond the single DI line, or is the release note exhaustive?
3. Is the HTTP client PSR-18 / PSR-7 compatible, or a bespoke class with its own contracts?
4. What are the SSL verification and timeout defaults — and are they configurable per call?
5. Does it expose curl_multi / concurrency, or is it strictly blocking single-request?
6. Is there a test suite and CI? What license?
7. What specific capability does this give us that Guzzle's curl request option does not — and has 1.0.6 changed that answer? (Current answer: no.)

Integration Approach

Stack fit

• Still poor as a bundle, acceptable as a source of one class. Decision rule unchanged: if we cannot lift the client class out cleanly in the spike, we stop and write a 150-line adapter over Guzzle's CurlHandler instead.
• 1.0.6 makes the "lift the class out" step slightly easier to justify: the only thing that changed upstream is the part we were going to delete, which is a clear signal the bundle layer is Symfony-coupled glue with no independent value.
• Target shape in our app unchanged: App\Http\Contracts\HttpClient interface, a CurlHttpClient implementation (extracted code), bound as a singleton, with a fake implementation for tests.

Migration path

1. Audit — read every source file (small repo), record license, curl option defaults, error handling, and re-diff composer.json against the pre-1.0.6 state. The constraint question is now the first thing to check, not the last.
2. Spike — instantiate the client class directly in php artisan tinker with no container involvement. Confirms whether the class is standalone.
3. Extract — vendor the class into app/Support/Http/ (or a private first-party package), strip Symfony annotations/DI, add strict types, fix PHP 8.x deprecations.
4. Wrap — interface + singleton binding + fake; route new call sites through the interface only.
5. Validate — parity tests against Http::fake() for timeout, TLS failure, 4xx/5xx, and malformed-response behavior. Do not treat 1.0.6 as a correctness signal; the release note gives no reason to believe HTTP behavior changed.
6. Decide — keep the extracted class only if it demonstrably does something Guzzle cannot. Default outcome: replace with Http client and delete.

Compatibility

• Verify ext-curl in our runtime image; confirm no reliance on libcurl features absent from our base image.
• If extracted, we control the PHP constraint — target the current LTS (8.2/8.3).
• Do not attempt to satisfy the original composer constraints by pinning old Symfony components; that creates a second, shadow framework inside the app. The 1.0.6 note referencing Symfony 5.2 APIs is a reminder that the bundle's dependency tree tracks Symfony, not Laravel.

Sequencing

• Audit + constraint diff + spike (0.5 day) → go/no-go → extract + wrap (1–2 days) → parity tests (0.5 day) → rollout behind interface.
• Hard gate unchanged: no production traffic until the interface and fake exist.
• 1.0.6 does not open a new window or urgent action; there is no security fix forcing a version bump.

Operational Impact

Maintenance

• We still inherit ~100% of maintenance. One patch release in four-plus years is not a support commitment — it is a maintainer clearing a deprecation warning in their own build. No upstream roadmap, no security advisories to watch, no Dependabot signal beyond our own fork.
• Provenance note updated: "forked from metaer/curl-wrapper-bundle @ 1.0.6 (Symfony DI deprecation fix only), prior release 2021-04-27."
• Still requires a named owner. Bus factor 1 upstream; 2 stars and 0 dependents means zero ecosystem pressure.

Support

• No docs beyond a README, no issue triage, no community. Onboarding cost is low for the code (it's small) and high for the decision — and 1.0.6 gives new engineers a fresh, visible example of the package's only recent activity being Symfony plumbing, which sharpens the "why aren't we using the framework's HTTP client?" question.
• Internal runbook needed: known-bad curl option defaults, error mapping, and rollback path.

Scaling

• Unchanged and unaffected by this release: blocking, single-request curl with no pooling, keep-alive management, retry/backoff, circuit breaking, or concurrency unless it exposes curl_multi. Under load this is measurably worse than Guzzle's pooled handler.
• Stateless, so horizontal scaling is unaffected — but every request pays handle-creation overhead and occupies a PHP-FPM worker for the full call duration, including a hung upstream with no timeout.
• No middleware/event hooks, so tracing, metrics, and structured logging must be bolted on manually at the interface boundary.

Failure modes

• TLS verification disabled by default (must verify explicitly before any production use). Not addressed in 1.0.6.
• No default timeout → worker exhaustion during upstream degradation; the classic cascading failure. Not addressed in 1.0.6.
• curl_exec returning false with no exception → silent bad data propagation. Not addressed in 1.0.6.
• Unclosed handles / handle reuse across requests → memory growth in long-running workers (Octane, queue workers).
• PHP 8.x deprecation noise in logs, with a future fatal at PHP 9. 1.0.6 fixes exactly one deprecation, in a layer we would not ship.
• New, low-severity: if 1.0.6 bumped Symfony constraints, a future composer update in a fork could resolve a different component graph than the one we validated — pin the fork.

Ramp-up

• Comprehension: hours. It is a small, simple codebase.
• Trust: the problem, marginally improved but not resolved. One maintenance release in four years, scoped entirely to Symfony DI, is consistent with "low-effort upkeep of a frozen project," not with active stewardship. The 2-star / 0-dependent / no-security-policy profile is unchanged, and the HTTP path — the only part we would actually run — has received no attention in this release.
• Recommendation: unchanged — do not adopt as a dependency. Re-read composer.json for constraint drift from 1.0.6, then use the package as a reference implementation at most. Keep Laravel's HTTP client; if a raw-curl capability is genuinely required, close that gap with Guzzle's curl request option or a small first-party adapter we own.