Wanna Speak Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM needs to flag is a framing mismatch: despite being catalogued here as a "Laravel/PHP package," yproximite/wanna-speak-bundle is a Symfony bundle. Yproximite is a Symfony shop, and the package name plus the -bundle suffix indicate it ships a Bundle class, a DependencyInjection extension, a config tree, and service definitions — none of which Laravel autoloads. There is no service provider, no facade, no publishable config.

What is genuinely reusable is the thin slice underneath that scaffolding: an HTTP client wrapper around WannaSpeak's REST API (likely Guzzle or Symfony HttpClient) plus whatever response parsing exists. That is realistically the 20% of the package worth keeping. The remaining 80% — DI wiring, configuration tree, Symfony event integration — is throwaway in a Laravel context.

Integration feasibility. High, provided we scope to the client layer. The domain surface is narrow (click-to-call, SMS, DID/number provisioning, call stats) and the underlying transport is plain HTTP. A realistic effort estimate is 2–4 days for a spike plus a clean Laravel-side adapter. There is no data migration burden: with 0 dependents, this is almost certainly a greenfield integration rather than a replacement.

Technical risk. This is where the package grades poorly:

• Abandoned. Archived, last release 2021-09-30, 0 stars, 0 dependents. No security triage, no issue response, no PHP 8.2/8.3/8.4 compatibility guarantee.
• Dependency drift. Symfony constraints are likely ^3.4|^4|^5. Composer will almost certainly conflict against Laravel 10/11, which pulls Symfony 6/7 components. This is the highest-probability failure and it surfaces as a blocked framework upgrade, not as a runtime bug — the worst kind of surprise.
• Provider drift. WannaSpeak is a proprietary French VoIP vendor. The bundle targets some historical version of their API; nothing in the repo proves it still matches production. No integration test suite against a live or sandbox endpoint.
• Transport semantics unknown. Retry, timeout, and error-mapping behaviour is undocumented. For billable operations (SMS, calls, number provisioning) that ambiguity is a cost and idempotency risk, not just a code-quality nit.
• Opportunity score of 4 correctly reflects a narrow, region-specific telephony niche with a single vendor.

Key questions.

1. Which WannaSpeak API version does the client target, and does it still match the vendor's current contract?
2. What is the credential model — account ID + API key, per-subaccount keys, rotation policy?
3. Which capabilities do we actually need? If it is one or two endpoints, a reimplementation beats a fork.
4. Is the licence permissive enough to fork and vendor internally? Check LICENSE before planning around it.
5. What are composer.json's PHP/Symfony constraints, and does it depend on Symfony's EventDispatcher (not interchangeable with Laravel's)?
6. Is there a supported alternative — direct REST integration, an official SDK, or a different EU telephony vendor (Twilio, Vonage, OVH)?

Integration Approach

Stack fit. Assume a Laravel application. Do not composer require the bundle. Evaluate three options:

• Option A — Fork and de-Symfony (preferred if the client is non-trivial). Strip the Bundle/DependencyInjection classes, retain the client and response objects, publish as an internal package (acme/wannaspeak-client). Contained blast radius, preserves whatever endpoint knowledge the original author encoded.
• Option B — Reimplement a thin client. If the required surface is 3–5 endpoints, 200–400 lines over Guzzle or Laravel's Http facade is cheaper than owning a fork. Lowest long-term cost.
• Option C — Shim the bundle into Laravel. Technically possible by booting the Symfony extension manually; high friction, no payoff. Reject.

The package is best treated as a reference implementation and API-contract documentation, not a dependency.

Migration path. Greenfield — there is no installed base to migrate. If a hand-rolled cURL script exists in the codebase today, port it behind a TelephonyClient interface so the vendor remains swappable, and cut over endpoint by endpoint with the old path retained as a fallback until parity is proven.

Compatibility. Target PHP 8.1+ and Laravel 10/11, Guzzle 7. Pin psr/http-client explicitly. Replace any Symfony event dispatching with Laravel events; replace any Symfony config tree with config/services.php entries backed by environment variables and a secret manager.

Sequencing.

1. Spike (2 days): read the source, enumerate endpoints actually used, validate the API contract against a sandbox or test credential before writing production code.
2. Decide A vs B based on the endpoint count the spike reveals.
3. Wrap: TelephonyClient contract + WannaSpeak adapter; credentials in env/secret store, never in config/ committed files.
4. Test: contract tests with Http::fake() / Guzzle MockHandler, plus exactly one live smoke test gated behind a CI flag. Mocked tests alone will not catch provider drift.
5. Roll out behind a feature flag; queue any call that sits on a user-facing request path.

Operational Impact

Maintenance. We own it outright. No upstream, no patches. Budget 1–2 days per quarter, or explicitly freeze the code and treat it as stable-until-broken. Register it in the dependency/tech-debt log with an owner name — abandoned packages without a named owner rot silently. The dominant recurring cost is not bug-fixing; it is composer resolution conflicts that block Laravel/PHP upgrades. Isolating the client in its own internal package with loose constraints is the mitigation.

Support. Zero community support — 0 stars, 0 dependents, no Stack Overflow corpus. WannaSpeak will support their API, not this wrapper. Onboarding documentation should point at the vendor's API docs, not the bundle's README.

Scaling. Synchronous HTTP to a French endpoint, realistically 200–800 ms per call. Any use in a request path (a click-to-call button in an agent UI, for example) must be queued. Rate limits are undocumented — assume they exist and implement exponential backoff. For billable operations, add idempotency keys: a retried SMS or a retried DID order is real money and confusing customer-facing behaviour.

Failure modes.

• Credential expiry/rotation → 401s and silently dropped calls. Needs alerting on auth failures, not just on exceptions.
• Provider API breaking change → hard outage with no patch path. Mitigated only by the adapter interface keeping a second vendor reachable.
• Timeout on the web request path → user-facing latency. Mitigate with queues plus aggressive timeouts.
• Partial failure in number provisioning → orphaned DIDs and recurring billing for resources nobody is using. Needs a reconciliation job.
• Composer lock breakage on framework upgrade → the most likely real-world incident; it blocks unrelated work.
• GDPR: phone numbers are personal data. Log scrubbing and EU data-residency review are required, and are easier to get right at the adapter boundary than retrofitted.

Ramp-up. Small codebase; any mid-level engineer can read it in a day. The learning curve is entirely in the vendor's API semantics — number lifecycle, subaccounts, billing units — not in the PHP. Given the low opportunity score and archived status, the honest recommendation is: pursue only if telephony is a genuine roadmap requirement, and then as a forked or reimplemented client, never as a direct dependency.