- Is mrad/notifications-bundle compatible with Laravel?
- Based on the technical evaluation, no: it is a Symfony bundle, not a Laravel package. The repository uses DependencyInjection extension files and has no Laravel service provider, so Laravel's container will not auto-wire it. Treat it as reference source rather than a Composer dependency for a Laravel application.
- How do I install mrad/notifications-bundle in a Laravel app?
- You can technically run composer require mrad/notifications-bundle, but in a Laravel project it is not expected to resolve cleanly or register automatically. The assessment recommends a throwaway composer require in a scratch container against your actual PHP version to confirm constraints first. Do not add it to a Laravel app expecting a service provider or publishable Laravel configuration.
- Does mrad/notifications-bundle support multi-channel notifications like mail and database?
- The package description claims multi-channel delivery for mail, database, and more, but the technical assessment found a thin fire-and-forget wrapper over the Pusher HTTP API. It has no persistence, read state, or channel abstraction. Verify the actual code before relying on mail or database channel claims.
- Does mrad/notifications-bundle support Laravel queues, retries, or failure callbacks?
- The assessment says no: it is trigger and forget, with no queueing, retry, or failure callback. The overview's queue-ready claim is not supported by the code review. Silent notification loss is the default behavior, and there is no hook to observe it.
- Which Laravel and PHP versions does mrad/notifications-bundle support?
- Version support is not confirmed in the evaluation, but the bundle appears to come from the Pusher SDK v2 or v3 era. The assessment expects it may only resolve under PHP 5.x or 7.x and likely fails on PHP 8. Check composer.json for symfony/framework-bundle versus illuminate/support constraints and run a resolution test.
- Is mrad/notifications-bundle maintained and safe for production?
- Risk signals include 7 stars, 0 dependents, a single maintainer, and no visible CI or release cadence. It is unmaintained and handles production Pusher credentials, so audit it before it touches anything sensitive. It is not recommended for production Laravel notifications.
- How does mrad/notifications-bundle compare to Laravel's built-in notifications?
- Native Laravel notifications and Broadcasting cover the same notification and broadcast ground with maintained surfaces. This bundle adds near-zero value over calling pusher/pusher-php-server directly and carries framework mismatch risk. For Laravel, use built-in notifications or a small Notifier interface.
- Can I use mrad/notifications-bundle with Pusher, Reverb, or Ably?
- It is built around the Pusher HTTP API and hard-codes Pusher semantics at call sites. Swapping to Reverb, Ably, or Mercure would be a refactor, not a configuration change. Use Laravel Broadcasting or your own abstraction if you need transport flexibility.
- How do I test notifications if I use mrad/notifications-bundle?
- The package has no delivery guarantees or failure hooks, so testing can only confirm the outbound HTTP call, not actual delivery. Prefer wrapping your own Notifier interface and faking that in tests. If evaluating the bundle, use a scratch container and mock the Pusher HTTP client.
- What are the best alternatives to mrad/notifications-bundle for Laravel?
- Use native Laravel Broadcasting with Pusher for Laravel services, which takes roughly half a day to one day for configuration and client wiring. Or call pusher/pusher-php-server directly behind your own Notifier interface when you want the transport isolated for later swap. Porting this bundle's logic into a local adapter only makes sense if an existing client already depends on its exact payload shape.