- Is johnkrovitch/notification-bundle a Laravel package?
- No. It is a Symfony bundle built around Symfony's kernel, bundle, and DI-extension model, not Laravel's service provider and config repository model. There is no Laravel service provider, facade, or Notifiable trait, so it will not behave like a native Laravel package. Treat it as a Symfony dependency that would need a wrapper before it fits a Laravel application.
- Can I install johnkrovitch/notification-bundle in a Laravel 10, 11, or 12 app with Composer?
- In practice this is blocked by dependency resolution. The v1.0 release targets Symfony 5, while modern Laravel versions resolve symfony/* at ^6.2 or ^7.0, so Composer will likely refuse the install or force an incompatible downgrade. The package also ships as a bundle rather than a standalone library, so there is no clean composer require path into Laravel. Integration would require forking and stripping the Symfony container coupling.
- Which Symfony and PHP versions does this notification bundle support?
- The v1.0 release notes declare Symfony 5 support, which is already past end of life for most 5.x lines with 5.4 in security-only support. Supporting Symfony 5 does not by itself confirm PHP 8.2+ readiness or updated transitive constraints. You should inspect the composer.json for the exact php and symfony/* floors before relying on it.
- Does johnkrovitch/notification-bundle still depend on SwiftMailer for email notifications?
- That is unresolved on the available evidence. The v1.0 release notes are silent on SwiftMailer removal, and without the post-release composer.json the mailer dependency cannot be confirmed. If the legacy mailer survives, mail delivery is a hard blocker because SwiftMailer is abandoned and unsupported on current PHP versions. Verify the composer.json and the mail channel implementation before planning any email use.
- What delivery channels does the notification bundle implement?
- The package advertises configurable delivery channels and separation of notification content from transport concerns, but the published notes do not enumerate which channels exist. This question was left unanswered in prior reviews and is still not addressed by the v1.0 release. You will need to read the source to see whether it covers mail, database, broadcast, SMS, or in-app messages.
- Is johnkrovitch/notification-bundle actively maintained?
- The v1.0 tag is evidence of a live maintainer and a shipped release after roughly a five-year gap, which improves the outlook from high risk to moderate. It is a heartbeat rather than a maintenance cadence: it is a single-maintainer project with negligible dependents and no broader ecosystem validation. Shipping a first stable release onto a sunset Symfony generation in 2025 also says something about upgrade velocity.
- How does this bundle compare to Laravel's native notification system?
- Laravel already ships Notifiable, the Notification facade, mail, database, broadcast and SMS channels, and queue integration out of the box. This bundle overlaps that functionality while adding integration cost, so it competes with the platform instead of complementing it. Only a channel adapter that exceeds native Laravel parity would justify extracting anything from it.
- Can I use this notification bundle next to a legacy Symfony service in the same estate?
- Yes, that is one of the two realistic scenarios. If you already run a Symfony 5 service, the bundle integrates through Symfony's service container and keeps messaging logic out of your controllers. It is not a bridge into Laravel though, so it does not reduce integration work on the Laravel side of the estate.
- How do I test notifications defined in this bundle?
- The main selling point is that notifications are reusable, testable units with content separated from transport, so definitions can be asserted without sending anything. Channel delivery can be swapped or stubbed because channels are registered through configuration in the service container. Whether CI actually runs a PHP and Symfony matrix for the package itself is unclear, so do not assume upstream test coverage exists.
- Can I fork the bundle or extract just the channel adapters into Laravel?
- Forking is possible, and a tagged 1.0 makes pinning to 1.0.x meaningful if you ever do it. The realistic path is extracting a specific channel adapter that beats Laravel's built-in channels rather than porting the whole bundle. Expect real work: configuration, channel registration, and dispatch all live in the Symfony bundle layer, and nothing in the release made that wrapper optional.