Weave Code
Monitor Bundle Laravel Package
novosga/monitor-bundle
The NovoSGA Monitor Bundle is a Symfony/PHP package that adds a real-time monitoring dashboard to NovoSGA queue management. Supervisors can track units, service points, waiting and in-progress tickets, attendance status, and queue performance from one screen, helping managers monitor attendance flow...
NovoSGA v2 monitor module.
Frequently asked questions about Monitor Bundle
- Is novosga/monitor-bundle a Laravel package?
- No. It is a Symfony bundle, shipped with a bundle class, a DI extension, and service wiring, and it is part of the NovoSGA queue-management ecosystem. It has no Laravel service provider, no facade, and no Laravel-idiomatic config publishing, so it will not auto-register in a Laravel app. Treat it as a standalone PHP/Symfony dependency rather than a Laravel integration.
- How do I install novosga/monitor-bundle in a Symfony application?
- Run composer require novosga/monitor-bundle, register the bundle in your Symfony application, and configure the transport it uses. The installation is straightforward on a Symfony stack. Note that v2.3.0 requires the host application to already be on Symfony 7.4 LTS, which in turn requires PHP 8.2 or newer.
- Which Symfony and PHP versions does v2.3.0 require?
- v2.3.0 bumps the Symfony constraint to ^7.4 LTS (up from ^7.1). Because Symfony 7.4 requires PHP 8.2 or higher, that becomes your effective runtime floor. Projects still on Symfony 7.1 through 7.3 are locked out of v2.3.0 even though it ships as a minor release under semver.
- Can I use this Symfony bundle inside a Laravel application?
- Not idiomatically. If the requirement is monitoring a NovoSGA deployment, this is the intended component, but if the requirement is observability inside your Laravel app, it is the wrong tool and incurs permanent framework-coupling debt. The viable paths, in order of preference, are: do not adopt and use a Laravel-native equivalent, run a small Symfony sidecar that hosts the bundle and expose it over HTTP or a queue, or consume the classes standalone only if you verify namespace by namespace that they carry no bundle-registration dependency.
- What does the NovoSGA monitor dashboard actually display?
- It provides a real-time monitoring dashboard for NovoSGA queue management. Supervisors can track units, service points, waiting and in-progress tickets, attendance status, and queue performance from a single screen. That makes it useful for monitoring attendance flow and improving service desk efficiency, not for general application observability.
- Does the v2.3.0 Envelope timezone change break existing consumers?
- The release passes the unit timezone to all Envelope instances, so Envelope payloads now carry the originating unit's timezone. That is a data-shape change on the wire rather than a pure bug fix, so anything that parses, stores, or displays serialized Envelopes must tolerate the new or changed field. It is worth confirming with the maintainer whether the field is additive and optional for consumers, and whether there are database or transport schema implications. No migration guide has been published.
- Is v2.3.0 a safe upgrade from v2.2.x?
- It is a maintenance release with low-to-moderate technical risk: there is no security advisory and no documented removal of public API. The moderate rating comes from two things landing together in a minor version: the Symfony ^7.1 to ^7.4 constraint bump and the Envelope timezone payload change. Watch for the fact that chores such as phpstan 2, phpunit 11, and phpcs 4 can hide signature-level tightening in a small codebase.
- How should I sequence the Symfony 7.4 upgrade and the v2.3.0 bump?
- Inventory your current versions first with composer show symfony/framework-bundle and confirm your PHP version, since Symfony 7.4 needs PHP 8.2 or newer. If you are on Symfony 7.1 through 7.3, upgrade Symfony to 7.4 first, resolve the deprecations, and ship that change. Only then take v2.3.0, and do not bundle both upgrades into a single deploy.
- Is the v2.2.x line still supported?
- There is no documented support window or LTS statement for the v2.x line, and 2.2.x is effectively cut off from v2.3.0 by the Symfony 7.4 floor. That is a question to raise with the maintainer before you plan a long-lived deployment. Also worth confirming is whether automated dependency PRs are merged to the release branch without review.
- What Laravel-native alternatives should I consider instead of this bundle?
- If your requirement is observability in a Laravel application, use Laravel Telescope, the Sentry SDK, or OpenTelemetry PHP instead. Those integrate with Laravel's HTTP and kernel model without pulling in Symfony bundle registration. Adopting a Symfony bundle to satisfy a Laravel observability need gives you no functional gain and a permanent framework-coupling cost.
Weaver
How can I help you explore Laravel packages today?