- Can I use multiinfo/scheduler-bundle in a Laravel application?
- Not directly. The package is a Symfony bundle from vendor monark-it, named after the MultiInfo Polish SMS/MMS gateway, and Symfony bundles do not use Laravel's service provider discovery or package auto-registration. Composer may install it, but you get no facade, config file, artisan command, or schedule entry out of the box. The practical path is to treat the repository as reference material for the MultiInfo API contract and reimplement the logic natively.
- What does multiinfo/scheduler-bundle actually do?
- Per the technical evaluation, the vendor namespace and Bundle suffix point to a Symfony bundle that schedules and dispatches SMS messages through the MultiInfo gateway. It is not a general-purpose Laravel task scheduler, despite a package description that only mentions scheduling tasks in Symfony. The reusable value is protocol knowledge: request signing, payload shaping, scheduling semantics, and retry behavior.
- Why won't the bundle auto-register in Laravel like other Composer packages?
- Laravel discovers packages through ServiceProvider classes and extra.laravel metadata, while Symfony bundles are registered manually in config/bundles.php and expose Bundle subclasses with DependencyInjection extensions. Those are different extension models even though both live on Composer and share PSR interfaces and DateTime utilities. Without a Laravel-aware provider, nothing in the bundle is ever bound into your container.
- Will Composer install it in a Laravel 10 or 11 project on PHP 8.2?
- It may resolve, but the evaluation expects Symfony 4/5 and PHP 7.x to 8.0 version constraints, which can fail dependency resolution outright on a modern Laravel stack. Even when installation succeeds, resolution is not integration: there is still no config publication, command, route, or facade. Check the declared constraints in composer.json before investing any time.
- Does the bundle handle retries, idempotency, or delivery receipts?
- The assessment flags this as an open question, since it is unclear whether the bundle owns scheduling and retry semantics or merely wraps immediate sends. Verify by reading the client and scheduler classes directly in the repository rather than trusting the README. If it turns out to be fire-and-forget, add queue retries, exponential backoff, and an idempotency key before trusting it in production.
- How do I port the bundle's scheduling logic into a Laravel app?
- Clone the repository and read the client and scheduler classes instead of installing the package. Lift the domain logic, meaning request signing, payload shaping, and retry behavior, into a class such as App\Services\MultiInfoClient built on Laravel's HTTP client. Then wrap sends in a queued job and register the timing in routes/console.php or the console kernel. The evaluation estimates one to three days of engineering for this native reimplementation.
- How do I schedule recurring SMS jobs in Laravel without the bundle?
- Use Laravel's own scheduler plus the queue: a SendSmsJob dispatched from a schedule() entry gives you cron syntax, timezone handling, overlap protection, and failed-job retries out of the box. That replaces the Symfony DI extension and configuration tree with framework-native code you already know how to debug. Keep the job small and let the queue worker handle backoff.
- How should I store MultiInfo credentials in a Laravel application?
- The evaluation warns that SMS credentials are high-value secrets, and it is unclear whether the bundle supplies them through environment variables, DI parameters, or config files that might be committed. Do not copy a bundled config file into your repository without review. Keep credentials in .env, read them through config() with a cached config, and audit any logging path that could leak tokens or message bodies.
- Is multiinfo/scheduler-bundle production-ready and actively maintained?
- The adoption signals are weak: one star, zero dependents, a composite score around 0.035, and no evidence of CI, test coverage, or a release cadence in the metadata. There is no community to catch regressions, and the package is a thin regional wrapper around a Polish gateway. Confirm the last commit date against the current Symfony LTS cycle and decide whether you want to depend on upstream for patches at all.
- How do I test a MultiInfo SMS integration in Laravel, and what are the alternatives?
- Use Http::fake() to assert the outbound request shape, including signing, payload fields, and recipient format, without touching the real gateway. Add a feature test that dispatches the queued job and asserts it lands on the right queue with the right delay. As for alternatives, the sensible one is your own thin client plus a job and a schedule entry; if you fork any of the bundle's logic, pin the fork to a commit SHA and cover it with your own tests.