- What is mannew/hipchat-bundle used for?
- It is a Symfony bundle that wires HipChat room notifications into a Symfony service container. It exposes a hipchat service that wraps the standalone HipChat PHP SDK so application events can send messages and alerts to team rooms. Configuration holds credentials and room settings. It is not a Laravel package and has no Laravel service provider, facade, or publishable config.
- Can I use mannew/hipchat-bundle in a Laravel application?
- No. The package ships a Symfony dependency-injection extension, configuration tree, and service definition, with no Laravel ServiceProvider, facade, config publishing, or Laravel version constraint. Composer might install it, but Laravel will not auto-wire the hipchat service. Treat the repository as reference source for the pattern, not as a Laravel dependency.
- Does it support Laravel 10, Laravel 11, or newer?
- There is no Laravel support at any version. The bundle targets Symfony 2 and, after release 1.4, Symfony 3; it has no Laravel integration surface. Laravel 10 and 11 are far newer than the bundle's framework ceiling. You would need to rewrite the integration rather than expect compatibility.
- Which Symfony versions are compatible with version 1.4?
- Release 1.4 widened Composer constraints so the bundle can be used with Symfony 3, up from Symfony 2. Both Symfony 2 and Symfony 3 are end-of-life; Symfony 3 reached EOL in November 2018. The bundle is not compatible with Symfony 5, 6, or 7 and has no Symfony Flex recipe. The upgrade path terminates at Symfony 3 rather than continuing to supported versions.
- Is the HipChat API still available for this bundle to call?
- No, not in the general case. Atlassian shut down HipChat Cloud in 2018 and ended HipChat Server/Data Center in 2020, so the bundle has no reachable endpoint for most users. The only narrow exception is an on-premises HipChat Data Center instance still running under a legacy support contract. That makes the integration failure upstream of the PHP code itself.
- How was mannew/hipchat-bundle installed and configured in a Symfony app?
- In a legacy Symfony 2 or 3 application you would require the package with Composer, register the bundle in the kernel, and configure credentials and room settings through the bundle configuration tree. The bundle then exposes a hipchat service that you inject where notifications are sent. Modern installs can hit Composer conflicts from the abandoned SDK and its Guzzle pins, so this is not a path for new applications.
- Why does Composer conflict with Guzzle or modern PHP versions?
- The bundle depends on the abandoned HipChat PHP SDK, which is PHP 5.x-era code and pins Guzzle 3.x or 5.x. Those constraints collide with current HTTP clients and with PHP 8 runtimes. Release 1.4 did not change PHP constraints, the SDK, or the Guzzle pin. In a legacy app you may need an isolated process to avoid dependency conflicts.
- Is mannew/hipchat-bundle safe for production?
- It carries high technical risk. The target SaaS is decommissioned, the transitive SDK is abandoned, the framework ceiling is end-of-life Symfony 3, and there is no meaningful test suite or security response path. Bundles of this vintage often read a static token from YAML and log request context, so credentials should be audited before any reuse. It is not recommended for new production work.
- Does the package have tests and active maintenance?
- There is no evidence of a meaningful test suite, and the contributor base is small with de minimis dependents. Release 1.4 is a constraint-widening release that allows Symfony 3 and adds a symfony/console suggest entry; it does not modernize the SDK or add Laravel support. A named contributor responding to a compatibility request is positive, but it is not a maintenance program. You should not rely on it for security fixes.
- What should I use instead for Laravel or Symfony chat notifications?
- Use a maintained integration for a current chat service such as Slack, Microsoft Teams, Mattermost, or Discord. In Laravel, notification channels and community packages cover those services; in Symfony, the Notifier component is the modern path. The bundle's architectural pattern, centralizing credentials in config and injecting one client, is still worth copying. What you should not do is wrap a decommissioned HipChat API.