Calisero Symfony Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM must flag: this is not a Laravel package. calisero/calisero-symfony is a Symfony bundle (Calisero\SymfonySms namespace, a bundle class, services.yaml wiring, a configuration tree). Laravel has no bundle loader and does not consume Symfony's DependencyInjection extension conventions, so the package cannot be auto-discovered or registered in a Laravel app the way the release notes imply. What is genuinely reusable in a Laravel codebase is the underlying Calisero PHP SDK (calisero/calisero-php); the bundle is only a thin DI/config wrapper around it. Architecture fit for a Laravel stack is therefore "adapter required," not "install and go."

Integration feasibility. Two distinct paths:

• Symfony service: composer require calisero/calisero-symfony:^1.0.1, enable the bundle, configure credentials — low effort.
• Laravel service: install the SDK directly, publish a config/calisero.php, bind a client singleton in a ServiceProvider, optionally expose a Facade, and route sends through a queued job. This is a few hundred lines of glue, entirely within our control, and avoids the unusable bundle layer.

Feasibility is high on both paths, but the effort estimate differs by roughly an order of magnitude, and the Laravel path means we own the integration code permanently.

Technical risk.

• Package rename is a hard break for Composer resolution. calisero/symfony-sms is no longer listed on Packagist. Any committed composer.lock, cached CI image, internal mirror, or Docker layer referencing the old name will fail on a cold resolve. The namespace is unchanged, so this is a source-of-truth break rather than a code break — insidious, because it passes locally on warm caches and fails in clean CI.
• Provenance must be re-verified. A package that changes its Packagist name while keeping its namespace is a classic supply-chain weak point. Before adoption, confirm vendor ownership of the new Packagist entry, that the repository URL resolves, and diff the 1.0.1 tree against 1.0.0. Treat 1.0.1 as a new dependency, not a patch.
• Maturity signals. A 1.0.1 release whose headline change is "the name was wrong and Packagist no longer lists the old one," plus broken README/CI/support URLs shipped in 1.0.0, indicates thin release discipline and effectively one maintainer. Semver 1.0.x gives little real stability assurance here.
• Naming churn. symfony-sms → calisero-symfony in a single patch release suggests the naming convention is still settling. Budget for a second rename.

Key questions.

1. Do we need the Symfony bundle at all, or is calisero/calisero-php sufficient for a Laravel integration?
2. Is the new Packagist vendor the same legal/operational entity as the old one? Was the repository transferred?
3. What are the PHP and framework version constraints, and does anything in the tree require symfony/framework-bundle at runtime?
4. Who maintains this, what is the bus factor, and what is the issue-response history?
5. Does the SDK support idempotency keys, retry/backoff, delivery-status callbacks, and per-message cost accounting — the things we actually need from an SMS vendor?
6. What is the fallback if the vendor or package disappears? Is the SDK swappable behind our own interface?

Integration Approach

Stack fit. Poor as a drop-in for Laravel; good for Symfony. The correct framing for stakeholders: we are adopting an SMS SDK with a Symfony-flavored distribution, not a Laravel package. The bundle's DI surface (services.yaml, config tree, autowiring) has no Laravel analogue.

Migration path.

1. composer remove calisero/symfony-sms if present, then composer require calisero/calisero-symfony:^1.0.1 (or calisero/calisero-php for the Laravel route). No application code changes are required by the rename — the namespace is untouched.
2. Delete stale lockfile entries and re-resolve from a clean cache; purge CI caches and rebuild base images so no layer holds the delisted name.
3. For Laravel: add config/calisero.php, a CaliseroServiceProvider binding the SDK client as a singleton, an optional Calisero facade, and a SendSms job class. Keep the SDK client behind our own SmsSender interface so a vendor swap is a container rebinding, not a refactor.
4. Read credentials from the secret manager, not .env committed values.

Compatibility. Version 1.0.1 is effectively API-identical to 1.0.0, so compatibility risk is confined to Composer resolution and to whatever PHP/Symfony constraints the tree declares. Verify those constraints against our PHP runtime before merging; the notes say nothing about them.

Sequencing. (a) Provenance and code audit of 1.0.1; (b) timeboxed spike on a branch with an exact pinned version; (c) build the Laravel adapter layer and a queue-backed send path; (d) test against the vendor's sandbox with rate-limit and error responses; (e) canary one non-critical notification flow; (f) expand. Do not begin with transactional or auth-critical messaging.

Operational Impact

Maintenance. We will own the Laravel adapter indefinitely — the vendor ships no Laravel support. Pin the exact version (1.0.1, not ^1.0) until the naming settles and a second release confirms stability. Add a dependency-review step to CI that catches renames and delistings, since that is precisely the failure mode this release introduced.

Support. Broken badges, dead issue/support URLs, and a package name that had to be corrected post-release all point to limited operational rigor upstream. Assume no SLA from the maintainer and treat vendor support as coming from Calisero the SMS provider, not from the open-source package. Confirm a commercial support path exists before this touches production traffic.

Scaling. Throughput is bounded by the SMS provider's rate limits, not by the package. All sends must go through a queue with concurrency caps, exponential backoff on 429/5xx, and per-provider batching. Log message IDs and delivery receipts so volume and failure analysis are possible; the package will not do this for us.

Failure modes.

• Cold-resolve failure in CI or a fresh deploy from the delisted calisero/symfony-sms name — highest-probability, highest-annoyance failure.
• Silent delivery failure: SMS is fire-and-forget by nature; without receipt polling, "sent" and "delivered" get conflated and incident detection is delayed by hours.
• Credential exposure via misconfigured env or verbose exception logging that dumps request payloads.
• Abandonment or a second rename, leaving us on an unmaintained pin.
• Adapter drift: our ServiceProvider silently diverges from SDK breaking changes because nothing tests it.

Ramp-up. Low for the SDK itself — a mid-level engineer can wire it in a day. The real cost is (a) Symfony DI familiarity if anyone tries to reuse the bundle, and (b) the adapter layer, which needs a design owner, interface tests, and a documented vendor-swap runbook. Plan roughly a sprint for a production-grade Laravel integration including queueing, receipt handling, and observability, versus an afternoon for a Symfony service that already uses bundles.

Recommendation. Adopt the SDK (calisero/calisero-php) behind our own interface; do not adopt the Symfony bundle in a Laravel context; treat 1.0.1 as a provenance re-review plus a Composer hygiene task, not a feature upgrade.