- Is pierrerolland/hipchat-bundle a Laravel package?
- No. Despite being distributed on Packagist and often evaluated alongside Laravel notification packages, it is a Symfony bundle: it ships a bundle class, DI configuration, and ready-made services for Symfony applications rather than a Illuminate service provider or NotificationChannel. Laravel developers should treat it as reference source code for the HipChat v2 REST calls, not as a drop-in dependency. If you want it in Laravel you would port the API logic into your own notifier or notification channel.
- Does pierrerolland/hipchat-bundle still work now that HipChat is shut down?
- The code may still execute, but there is no HipChat API left to talk to. Atlassian announced HipChat end of life in 2018 and shut down HipChat Server and Cloud in 2019, so every endpoint this bundle targets is retired. Any request will fail at the network or DNS layer regardless of how you configure credentials. The package is now only useful as a historical reference implementation.
- Can I install pierrerolland/hipchat-bundle in a modern Laravel or PHP 8 application?
- Realistically, no. The single 1.0.0 release dates from 2016-06-22 and targets the Symfony 2.x era with PHP 5.6 through 7.0/7.1 constraints on its Symfony and HTTP client dependencies, so Composer will normally refuse to resolve it against PHP 8 and current framework versions. Forcing it in with ignore-platform-reqs leaves you with code that will not run on modern PHP without edits. The practical path is to read the source, copy the HipChat API calls you need, and reimplement them in your own service.
- Which Laravel and Symfony versions does this HipChat bundle support?
- There is no published support matrix. The release note for v1.0.0 is a single sentence with no changelog, no compatibility table, and no deprecation notices, and no later tags exist. From the 2016 publication date you should assume Symfony 2.x and PHP 5.6 to 7.0, not anything current. There is no Laravel version support at all, because the package was never built for Laravel.
- How do I install and configure pierrerolland/hipchat-bundle?
- In a period-correct Symfony project you would add it with Composer, register the bundle in AppKernel, and supply an API token plus default room through the bundle's configuration. The repository README is essentially empty, so there is no documented configuration reference, no example config file, and no guidance on credential sourcing. Anything you need beyond that has to be reverse-engineered from the bundle's service definitions and source.
- How do I send a HipChat room notification from Laravel without this package?
- HipChat's v2 REST API sent room messages with a POST to /v2/room/{room}/notification using a bearer token and a JSON body containing message, color, and notify fields. You can call that pattern from a queued job or a custom notification channel using Laravel's HTTP client, with the token stored in config and injected from the environment. Since the HipChat service no longer exists, this is only useful if you are migrating to a compatible self-hosted or replacement chat API. Laravel's first-class notification system shipped in 5.3, in August 2016, so a June 2016 package predates NotificationChannel entirely anyway.
- Is pierrerolland/hipchat-bundle maintained or abandoned?
- It appears abandoned. Version 1.0.0 was published on 2016-06-22 and remains the only tag, with no changelog, no upgrade notes, and no subsequent releases in roughly a decade. The repository shows no CI badges or meaningful test coverage, which is typical of a single-maintainer one-off bundle. Treat it as frozen code, not a supported dependency.
- What are the alternatives to pierrerolland/hipchat-bundle for Laravel notifications?
- Since HipChat itself is gone, the realistic alternatives are Laravel's built-in notification channels for Slack, Microsoft Teams, or Discord, all of which are actively maintained and first-party. If you need HipChat-shaped payloads for a migration or an archived system, write a small custom channel that posts to your replacement endpoint rather than reviving a dead SDK. For Symfony applications, a maintained HTTP-client-based service is preferable to this bundle in every respect.
- How should I test an integration that depends on this HipChat bundle?
- Do not test against the real HipChat API, because it no longer exists and no certificate, rate-limit, or protocol updates will ever arrive. If you must exercise legacy code paths, wrap the HTTP client behind an interface and fake it in tests, asserting the request URL, headers, and JSON payload rather than real network calls. The bundle ships no documented testing helpers, so you would be building that harness from scratch anyway. Most teams are better off deleting the dependency and testing their replacement notifier directly.
- Is pierrerolland/hipchat-bundle safe to use in production?
- The dominant risk is installability and dead-code liability rather than security. Its dependency graph is pinned to PHP 5.x-era versions, so installing it either fails or forces a partial upgrade of your application, and the latter is disqualifying. The vendor API is permanently offline, meaning no upstream bug fixes, rate-limit changes, or TLS updates, and a 1.0.0 tag with no documentation invites surprises under a stable version number. It is a reference artifact, not a production dependency.