- Does jp/firebase-notification-bundle work with Laravel?
- No. Despite being catalogued alongside Laravel packages, jp/firebase-notification-bundle is a Symfony2 bundle: it ships a Bundle subclass, a DependencyInjection Extension that loads a YAML config tree, and XML/YAML service definitions. Laravel never boots the Symfony FrameworkBundle, so there is no bundle auto-discovery, no Extension::load() config pipeline, and no ServiceProvider, publishable config, or facade. Making it work in Laravel is a port, not an install.
- Which Firebase Cloud Messaging API does this bundle use — legacy or HTTP v1?
- The bundle targets the FCM legacy HTTP API, hitting fcm.googleapis.com/fcm/send and authenticating with a server key. Google deprecated the legacy send APIs and shut them down in June 2024 in favour of the FCM HTTP v1 API with OAuth2 service-account credentials. If the sender still calls that endpoint, the package is not merely unmaintained, it is functionally non-functional. Confirming the endpoint and auth model is the single go/no-go question for any evaluation.
- Can I install jp/firebase-notification-bundle in a Laravel app with Composer?
- Unlikely to resolve cleanly. Symfony 2.8 reached end of life in November 2018, and modern Laravel pulls Symfony 6/7 components, so Composer will probably conflict on symfony/dependency-injection and symfony/http-kernel constraints, with transitive PHP pins potentially fighting your runtime too. Even if it installs, there is no Laravel integration to bind it into the framework.
- What Laravel package should I use instead for FCM push notifications?
- Use a maintained Laravel-native option that speaks HTTP v1. kreait/laravel-firebase handles service-account auth with an actively maintained SDK, and laravel-notification-channels/fcm fits Laravel's Notifiable/Notification abstraction and is queue-aware. Define a thin PushGateway interface in your domain and implement it against whichever you choose, so FCM-specific code stays at the boundary. Both eliminate the credential-model and API-lifecycle risk outright.
- How do I migrate from this bundle's legacy FCM calls to the HTTP v1 API?
- Do not rewrite the legacy calls, re-platform them. Swap the bundle for an HTTP v1 client, provision a service-account JSON, and route sends through a small gateway class the rest of your app depends on. That keeps the migration to days rather than weeks and gives you a queue and a support path. The legacy endpoint's shutdown means there is no incremental path that keeps the current sender alive.
- Does this bundle support topics, device groups, and data-only payloads?
- The package description claims single-device, topic, and device-group sends plus data payloads and platform-specific overrides, but nothing in the repository evidence confirms it. There is a single-sentence description, no documentation written for Laravel, and no sign of production use, so field-tested handling of token invalidation, topic conditions, and multicast limits cannot be assumed. Verify against the sender class before relying on any of it.
- Is jp/firebase-notification-bundle actively maintained and safe for production?
- Treat it as unmaintained. It has five stars, zero dependents, one author, no release cadence, and no evidence of production use anywhere. Combined with an end-of-life framework baseline and a retired API, it is not a dependency you can put behind a production notification path. If a scan surfaced it, confirm whether it is a live requirement with a named owner or a transitive leftover.
- What credentials does the bundle need — a server key or a service account JSON?
- As a Symfony2-era bundle it is built around a legacy FCM server key supplied through bundle configuration, typically via environment variables. Modern FCM requires OAuth2 service-account credentials and short-lived access tokens, which means token refresh logic the bundle almost certainly lacks. That credential-model gap is the main reason a maintained HTTP v1 client is the safer adoption.
- Should I fork the bundle and extract its sender class into my Laravel app?
- Only if a timeboxed spike proves the sender already targets HTTP v1, which is unlikely. A fork means owning the code indefinitely, including the OAuth2 token refresh it probably does not implement, and the extracted logic is exactly the part most likely to be dead against current Firebase. If you do go this route, lift the payload construction into a standalone class, register it in an App\Providers\NotificationServiceProvider, and replace the YAML config tree with a config/firebase.php array. Budget a few days on a five-star, zero-dependent package with no docs for your stack.
- Does the package have tests, and how would I test push notifications?
- There is no evidence of a test suite, and the repository gives no indication of whether the transport is mocked or whether retry logic, backoff, and response-body parsing exist. Testing a Laravel channel is straightforward: fake the HTTP client or bind a fake PushGateway implementation and assert the payload shape and per-message response handling. With this bundle you would first have to build that seam yourself.