Smsapi Bundle Laravel Package

Technical Evaluation

Architecture fit This is a fundamental framework mismatch, and it remains the first thing to establish. kch/smsapi-bundle is a Symfony 2 bundle, not a Laravel package. Its value is almost entirely Symfony Dependency Injection wiring — a *Bundle class, Resources/config/services.xml, a Configuration tree, and compiler passes that register the SMSApi client as a container service. Laravel has no bundle/kernel/compiler-pass/tagged-service model; its equivalents are service providers, facades, config/*.php files, and container bind/singleton calls. None of the bundle's own code executes under Laravel. The only reusable artifact is the transitive dependency on the SMSApi PHP client library, which can be consumed independently of Symfony.

The 1.6.2 release note — "Ustawienie tagów w serwisach" ("setting tags in services") — is a change to Symfony service-tag configuration in services.xml. This is precisely the layer of the package that has no Laravel analogue: DI tags exist to drive compiler passes and tagged-service injection, none of which exist in Laravel. The release therefore reinforces rather than revises the conclusion. The package continues to contribute zero net implementation value to a Laravel codebase; any capability it wires would be rewritten as a Laravel service provider regardless.

Integration feasibility Low via the stated artifact, moderate via its underlying dependency. composer require kch/smsapi-bundle will install the bundle and its symfony/* dependencies into a Laravel vendor tree, but the package will be inert — no auto-discovery, no registration, no config publishing. There is still no supported integration path: no Laravel service provider is shipped, and 1.6.2 does not add one. The realistic path remains to discard the bundle and wrap the SMSApi PHP client (or the vendor's HTTP API) in a Laravel service provider + facade + config file. That is an afternoon-sized task, not an integration project.

Technical risk High, and concentrated in dependency health rather than in the API surface:

• Dormancy, not maintenance. The package sat unreleased from 2016-06-01 until this 1.6.2 cut — roughly nine years. A single release with a one-line changelog is not evidence of a maintenance cadence; it is evidence of an occasional commit. There is still no visible test suite or CI, no security policy, and no disclosure channel.
• EOL framework dependencies. Symfony 2 reached end of life in November 2018. Unless 1.6.2 explicitly widened its constraints (unverified — no composer diff supplied), installing the bundle still pulls an EOL framework into a modern dependency graph.
• PHP constraint conflicts. Symfony 2-era packages typically constrain php: >=5.3.3 or ~5.4|~7.0 and pin Guzzle 3/5. Modern Laravel (10/11/12) requires PHP 8.1+/8.2+ and Guzzle 7. Resolution will either fail outright or require --ignore-platform-reqs workarounds that introduce runtime risk. The 1.6.2 note gives no signal that these constraints moved, and a service-tag change is not the kind of release that modernizes a dependency floor.
• No community signal. Historically 1 star, 0 dependents. One release does not create a downstream population that discovers CVEs or files issues. Effectively a private package that happened to be published.
• Release communication. The changelog is Polish-only and terse; there is no English-language release note, migration note, or deprecation notice. Any consumer must read the diff to learn what changed.

Key questions

• What changed in 1.6.2 beyond service tags — specifically, were the php, symfony/*, and guzzle constraints touched? This determines whether the install-time risk profile has moved at all.
• Was 1.6.2 tagged from a maintained default branch, and is there any commit activity between 2016 and now, or is this a one-off backport?
• What is the actual messaging requirement: transactional 2FA/OTP, order notifications, or marketing/bulk? Latency, throughput, and delivery-report needs differ sharply and determine whether SMSAPI is even the right vendor.
• Is SMSAPI's current official PHP SDK maintained and PHP 8-compatible? If yes, the bundle is irrelevant regardless of its release activity.
• Does the vendor publish a documented REST API with a stable contract we could call directly over HTTP without any SDK?
• What is the regional scope? SMSAPI is a Polish provider; sender-name registration, alphanumeric sender rules, and pricing are market-specific.
• What are the exit costs — is the vendor's API surface small enough to abstract behind our own SmsSender interface so we can swap providers without touching call sites?
• Who owns the wrapper, and what is our patch SLA if the client library breaks on a PHP upgrade?

Integration Approach

Stack fit Do not integrate the bundle. Treat it as a reference implementation at best — a demonstration of which client methods exist and which configuration knobs the vendor exposes. The correct stack fit for Laravel is: smsapi/php-client (or vendor HTTP calls) → our own SmsSender contract → a Laravel service provider binding the concrete driver → a facade for ergonomics → a config/sms.php with credentials and sender defaults sourced from env. This keeps the vendor behind an interface and makes a future provider swap a config change rather than a refactor. The 1.6.2 service-tag work has no counterpart in this design and should not be emulated.

Migration path There is nothing to migrate from — no prior Laravel usage exists, and 1.6.2 does not create one. The migration question is really "how do we adopt the underlying client without inheriting the bundle." Sequence: extract the capability list from the bundle's config schema and service definitions (send single, send bulk, delivery reports, sender-name handling, credential/auth mode), then reimplement that configuration surface natively in Laravel. The bundle's Configuration tree remains a useful checklist of the knobs SMSAPI exposes, even though its XML is unusable. Note that "setting tags in services" is not a capability — it is container plumbing with no adopter-visible feature.

Compatibility Compatibility must be proven before any design work is committed, and 1.6.2 does not resolve this question on its own. A one-hour spike should confirm that the client library installs cleanly on the target PHP version against the target Laravel version without --ignore-platform-reqs, and that the 1.6.2 tag did not narrow constraints further. If it does not install — and the Guzzle pin makes that likely — the options are (a) call the HTTP API directly with Laravel's Http client, bypassing the SDK entirely, or (b) fork the client to relax constraints and accept ownership of the fork. Option (a) is usually preferable for a surface this small; SMS send/bulk/delivery-report is a handful of endpoints and roughly 150 lines of code. Also verify encoding behavior against Polish diacritics, since GSM-7 vs UCS-2 decides segment count and therefore cost.

Sequencing

1. Read the 1.6.2 diff and confirm whether php/symfony/*/guzzle constraints changed (timeboxed, before anything else).
2. Confirm vendor and SDK viability on target PHP/Laravel.
3. Define SmsSender interface and DTOs (recipient, body, sender, idempotency key) — build this before any vendor code.
4. Implement driver: SDK-backed if viable, Http-backed otherwise.
5. Add service provider, config file, env validation at boot (fail fast on missing credentials).
6. Wire delivery through a queued job with retry/backoff and a per-provider rate limiter.
7. Add delivery-report ingestion (webhook or polled command) if the use case needs it.
8. Only then expose a facade to feature teams.

Operational Impact

Maintenance We own this integration end to end. The bundle remains effectively unmaintained: a single 1.6.2 release after a nine-year gap, a Polish-only one-line changelog, and no visible CI or security process. That does not constitute a support commitment, and it does not change the underlying dependency picture. If we adopt the underlying client, we likely inherit caretaking of that too, given Symfony 2-era pins. Budget a small but permanent maintenance line: PHP upgrade validation each cycle, Guzzle/Symfony transitive CVE review, and a documented fork point if the upstream client goes stale. Do not treat 1.6.2 as a signal that the package is back under active maintenance; treat it as a data point that the maintainer is reachable but not operating a release cadence.

Support Vendor support, if purchased, covers the SMSAPI HTTP service and account — not this bundle. There is no community to escalate to: no issue triage, no Stack Overflow footprint, no meaningful downstream population. Internal onboarding must rely on the vendor's API docs and the client source, not on package documentation, and certainly not on a Polish-language changelog. Ensure the vendor contract covers API deprecation notice windows, since an unmaintained client cannot adapt quickly to a breaking API change.

Scaling The bundle contributes nothing to scaling and nothing to constrain it — 1.6.2 included. Real scaling levers sit in our wrapper: dispatch sends through Laravel queues with a dedicated SMS queue and worker pool, apply a rate limiter sized to the vendor's throughput and concurrency limits, batch bulk sends rather than looping synchronously in request handlers, and persist send attempts for reconciliation. Cost scales with segment count, so enforce body-length validation and encoding choice at the DTO boundary rather than discovering overages in billing.

Failure modes Principal failure classes: authentication/credential rotation breakage (mitigate with boot-time config validation and a health check); vendor HTTP 5xx and timeouts (mitigate with bounded retries, exponential backoff, and idempotency keys so retries don't double-send); silent partial failure on bulk sends (mitigate by tracking per-recipient status, not a single bulk result); delivery-report gaps (mitigate with a polled reconciliation command and an alert on stalled status transitions); encoding-related segment inflation; and rate-limit rejection during traffic spikes (mitigate with queue depth alarms and limiter saturation metrics). Because the underlying client is old, assume limited built-in retry/backoff and implement it in our layer.

Ramp-up Learning the package remains near-zero effort and near-zero value, because we will not use it. The 1.6.2 release adds no ramp-up burden and no ramp-up benefit — service-tag configuration is Symfony-specific and unreadable as documentation of vendor capability. Learning the integration is modest: the vendor's send/bulk/delivery-report API is small and well-bounded, and a competent Laravel engineer can produce the provider, config, driver, queue job, and tests in a few days. The genuine ramp-up cost is organizational — agreeing on the SmsSender abstraction, encoding and cost rules, sender-name registration with the vendor, and on-call ownership for delivery failures. Plan for that, not for Symfony bundle onboarding.

Recommendation Do not adopt kch/smsapi-bundle. The 1.6.2 release does not change this: it is a Symfony service-tag configuration change in a package that cannot function in Laravel, and it arrives after a nine-year dormancy without evidence of CI, tests, or a security process. Before re-scoring dependency risk, check whether 1.6.2 moved the PHP/Symfony/Guzzle constraint floors — that is the only fact that could materially alter the install-time risk. Independent of the answer, evaluate SMSAPI's current official SDK for PHP 8 compatibility; if it is healthy, wrap it in a thin Laravel service provider behind an internal SmsSender interface. If it is not, call the vendor's HTTP API directly via Laravel's HTTP client — the surface is small enough that an SDK adds risk without adding much value. In all cases the abstraction layer, not the package, is the deliverable.