Rms Push Notifications Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for push delivery: This package is a fork of a Symfony 2-era bundle (richsage/RMSPushNotificationsBundle) that wraps the legacy APNS binary protocol and Google Cloud Messaging. It informs the decision mainly as a negative data point: the "buy" option here is a dead-end, so the real choice is between a maintained third-party SDK and a thin in-house service layer over APNS HTTP/2 + FCM v1.
• Framework fit / architecture review: Despite being filed under "Laravel/PHP," this is a Symfony bundle, not a Laravel package. That is itself a product decision input — if our services are Laravel, adopting it means writing and owning an adapter (service provider, config bridge, queue integration), which is real scope we'd have to justify.
• Tech-debt triage for legacy surfaces: The existence of a vendor fork with zero stars and zero dependents suggests someone patched it privately to keep an older Symfony app alive. That's a signal to inventory where it's used, not to standardize on it.
• Roadmap sequencing for notifications: Since the underlying transports it targets are deprecated (GCM was retired in favor of FCM; the APNS binary protocol was replaced by token-based HTTP/2), any roadmap item that assumes this package works is really a hidden migration item. Better to surface that cost now than mid-sprint.
• Vendor/dependency risk policy: A useful test case for a "no unmaintained transport dependencies" rule — push notification delivery touches credentials, certificates, and end-user devices, so abandonment risk is user-visible, not just internal.
• Reference material, not runtime dependency: Reading the fork's diff against upstream is a legitimate low-cost way to learn what a prior team changed and why, which can inform a small migration spike.

When to Consider This Package

Consider it only under narrow, largely historical conditions:

• You are maintaining a legacy Symfony 2.x application that already depends on the upstream richsage bundle, and this fork contains a specific patch (credential handling, a payload tweak, a PHP version fix) you need to keep that app running while it's being retired.
• You need to read the code to understand an inherited integration — as documentation of a past decision, not as a library to install.
• An internal audit requires you to account for every push-related dependency in the estate and this one shows up.

Look elsewhere in essentially every other case:

• New Laravel or modern Symfony work: the namespace, service wiring, and configuration model are wrong for the framework, and the transport protocols are obsolete. Evaluate actively maintained options instead — for Laravel, the notification channel ecosystem plus a maintained FCM/APNS SDK; for either framework, a thin internal abstraction that isolates the vendor SDK behind a PushSender interface.
• No maintainer signal: zero stars, zero dependents, no release or version data means no community backstop, no CVE triage, and no upgrade path. There is no one to escalate to when Apple or Google changes an endpoint.
• Compliance or security-sensitive contexts: push credentials are high-value secrets; an unmaintained package with an unknown patch history is hard to defend in a security review.
• Any product bet with a multi-year horizon: the dependency's lifespan is shorter than most roadmap horizons.

If push is genuinely important to the product, the decision worth funding is a short spike: pick a maintained SDK, wrap it, and measure delivery reliability — not a fork resurrection.

How to Pitch It (Stakeholders)

To executives: A candidate push-notification library surfaced from our dependency scan. On review, it's a fork of a Symfony 2-era bundle with no community adoption, targeting two transport protocols that Google and Apple have both retired. It is not a viable foundation for a feature customers depend on. The recommendation is no-go — the cost isn't the package, it's the invisible migration work and the on-call exposure of owning abandoned delivery code. I'd like a small, timeboxed evaluation of a maintained alternative instead; the spend is measured in days, and the alternative reduces the risk of silent notification failures that look like product bugs.

To engineering: This is a Symfony bundle, not a Laravel package — adopting it means writing our own adapter, and we'd still be speaking deprecated protocols. There's no maintainer, no release history, and no dependents, so we'd be the sole owner of any bug we hit. Proposal: treat it as reference material only, confirm whether it's already wired into anything in the estate, and if it is, scope that as a migration item rather than a dependency upgrade. If we want push in a Laravel service, we should agree on an internal PushSender interface and let the vendor SDK sit behind it so the next swap is a one-file change.