Calisero Symfony Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — worth stating up front, because the day-to-day workflow is different from what you're used to.

Install (note the new name):

composer require calisero/calisero-symfony

If you copy an old snippet or follow a cached tutorial, it will say calisero/symfony-sms — that name is gone from Packagist as of 1.0.1. The rename is install-name only: the namespace (Calisero\SymfonySms), bundle class, config tree and service IDs are unchanged, so nothing in your code needs to change on upgrade from 1.0.0.

Where to look first:

1. composer.json → confirm calisero/calisero-symfony appears (not the old name) and check the support URLs now point at the real repository.
2. The bundle class under Calisero\SymfonySms — that's your entry point for registration.
3. The package's config/ directory — the configuration tree is the contract you'll actually code against; read it before writing anything.

Symfony first use: register the bundle in config/bundles.php, then create the package config file (typically via config/bundles.php + a config/packages/*.yaml file). Inject the exposed service into a controller or command and send a message.

Laravel first use — the realistic path: don't install the bundle. Install the underlying SDK instead:

composer require calisero/calisero-php

Then wrap it in a small service provider + facade, or bind a configured client as a singleton. The bundle exists to do exactly that wiring for Symfony's container; in Laravel you're doing that wiring yourself, and pulling in a Symfony bundle just to get a DI extension you can't use is unnecessary weight.

Implementation Patterns

Symfony: constructor injection. The bundle's services are container-managed, so type-hint the client/service interface in your constructor and let autowiring resolve it. Avoid $container->get() — it hides the dependency and breaks as soon as the service ID changes.

Symfony: config-first, not code-first. Credentials and defaults belong in your YAML config, injected via the bundle's config tree. Keep secrets in .env and reference them from the config file rather than hardcoding. This is also how you run different credentials per environment without touching code.

Laravel: singleton binding. The pattern that works day-to-day:

// AppServiceProvider::register()
$this->app->singleton(SmsClient::class, fn () => new SmsClient(
    config('services.calisero.key'),
));

Then resolve it by type-hint in controllers, jobs and listeners. This mirrors what the bundle gives you in Symfony and keeps test doubles trivial to swap.

Queue it. SMS is a network call — never send in the request/response cycle. In Laravel, a ShouldQueue job wrapping the client is the natural unit; in Symfony, dispatch a message to a messenger transport. Either way you get retries for free, which matters because carrier APIs fail transiently.

Abstract behind your own interface. Both the bundle and the SDK are vendor surfaces. Define App\Contracts\SmsSender and implement it with the Calisero client, then bind the interface. If you ever swap providers, or if this package renames things again (see below), one class changes instead of every call site.

Multi-environment / multi-tenant. Because config and services are unchanged across 1.0.0 → 1.0.1, per-tenant credential handling works identically: resolve the client per tenant rather than binding one global singleton.

Gotchas and Tips

The rename is the whole release — and it's a trap for installs, not for code. calisero/symfony-sms is no longer listed on Packagist. Consequences to plan for:

• Lock files: a project pinned to calisero/symfony-sms won't resolve on a fresh composer install against Packagist. Update the requirement to calisero/calisero-symfony, then composer update calisero/calisero-symfony. Expect a diff in composer.json and composer.lock only.
• CI caches and Docker layers: a cached ~/.composer/cache referencing the old vendor name can produce confusing failures. Clear it before debugging anything else.
• No namespace change means no code migration. Don't let a "package renamed" note send you on a find-and-replace of Calisero\SymfonySms — that will break your build. Only the Composer package name moved.

Badges and links were broken. README CI/coverage badges and the support URLs in composer.json pointed at a nonexistent repository. If you're rendering package metadata (internal dashboards, dependency audits, licence reporting), refresh whatever cached those URLs — they were 404s, not a transient outage.

"Install-name only" means zero deprecations. Nothing is deprecated, no config keys moved, no service IDs changed. Upgrade is a lock-file change; there's no code path to test beyond confirming the container still compiles.

Debugging a bundle that "isn't there": in Symfony, a bundle that isn't in config/bundles.php produces missing-service errors that look like config problems. Check registration first, then bin/console debug:container for the actual service IDs. bin/console config:dump-reference <bundle-alias> shows the real config tree — use it instead of guessing key names from the README.

Laravel pitfall — don't try to shoehorn the bundle. Laravel has no bundle registration, and adding a Symfony bundle as a dependency buys you nothing. If you found this package while searching for an SMS integration, go straight to calisero/calisero-php and write the ten-line service provider.

Extension points: the bundle's services are the integration surface. If you need custom behaviour (logging, retries, message transformation), decorate the service in your container config rather than subclassing — decoration survives package updates, subclassing tends to break on minor bumps.

Watch the naming pattern. This release aligned the package name with the repository and the SDK (calisero/calisero-php). Treat any future install-name change the same way: verify the Composer name and support URLs in composer.json before trusting a README badge.