- Is neogen/bouncer-bundle a Laravel package?
- No. Despite being labeled as a Laravel/PHP package in some listings, neogen/bouncer-bundle is a Symfony bundle built around Symfony bundle conventions such as a DI extension, compiler passes, bundle registration, and a bundle config tree. Laravel has no equivalent registration mechanism, so it is not a drop-in Laravel package.
- Can I install neogen/bouncer-bundle in Laravel 10 or 11?
- Realistically, no. The last release is from 2017 and its Composer constraints will likely pin older Symfony and PHP versions, so composer require will usually fail on dependency conflicts before runtime. Even if forced in, the SwiftMailer filter integration cannot work on Laravel 9 or later because Laravel moved off SwiftMailer.
- What does neogen/bouncer-bundle actually do?
- It integrates Bouncer-style authorization into PHP applications using Symfony bundle wiring, letting you define abilities, assign roles, and enforce access control. It also includes SwiftMailer filter integration for bounce and complaint handling around SES/SNS notifications. The genuinely reusable surface is small: notification parsing, suppression-list state, and a send-time gate.
- Why does composer require neogen/bouncer-bundle fail on modern PHP?
- The package was released in 2017 and its Composer constraints almost certainly target Symfony 2.x/3.x and PHP 5.5 to 7.x. Modern Laravel and Symfony applications run PHP 8+ and current Symfony components, so Composer reports version conflicts. That failure happens at dependency resolution, before any code is executed.
- Is neogen/bouncer-bundle maintained or safe for production?
- No. It was last released on 2017-12-29, has zero stars and zero dependents, and shows no PHP 8 compatibility or security disclosure path. The code sits in the mail-sending path, so a defect can either block legitimate mail or silently allow mail to known-bad addresses. That blast radius makes an abandoned dependency a high-risk choice.
- Does neogen/bouncer-bundle support Symfony Mailer or PHP 8?
- There is no indication that it supports Symfony Mailer or PHP 8. It is built around SwiftMailer filters, and SwiftMailer was deprecated in favor of Symfony Mailer and removed in Symfony 6. Laravel moved off SwiftMailer at Laravel 9, so the filter integration is unusable on supported framework versions.
- How does neogen/bouncer-bundle handle SES bounce and complaint notifications?
- Its intended role is to parse SNS/SES notifications for bounce, complaint, and delivery types, maintain suppression-list state, and gate sending at send time. However, the repository context does not establish whether it exposes an SNS webhook or polls, whether it validates the SNS message signature and topic ARN, or where suppression state is stored. Those are exactly the design questions you must answer before trusting any bounce-handling code.
- Should I use neogen/bouncer-bundle for SES suppression list management?
- Not as a dependency. SES now provides native account-level suppression lists and configuration-set event destinations, which deliver much of the original value with no application code or maintenance burden. Enable those first, then evaluate whether you still need application-side visibility, audit trail, or CRM sync.
- What is a better alternative for bounce handling in Laravel?
- Start with SES account-level suppression and a configuration set with an SNS or EventBridge event destination attached to your sending identity. For app-side needs, implement a small Laravel service that validates SNS signatures and topic ARNs, handles notifications idempotently by mail.messageId, stores suppressions in a table with email, reason, timestamp, and source, and checks a cached lookup before send. Use Symfony Mailer events or Laravel mail events as appropriate, and skip the SwiftMailer filter approach entirely.
- How can I reuse ideas from neogen/bouncer-bundle without depending on it?
- Treat the repository as a design reference and port the concept, not the code. Read how it parses SES notification schemas, then implement an SNS subscription endpoint with signature and topic-ARN validation, idempotent handling keyed on mail.messageId, a suppression table, a cached lookup before send, and a dead-letter queue for unparseable notifications. Do not add the package to composer.json.