Watchdog Bundle Laravel Package

Getting Started

• First, confirm the package type. raneomik/watchdog-bundle is a Symfony bundle, not a Laravel package. Its composer.json will have "type": "symfony-bundle" and require symfony/framework-bundle (or similar). There is no extra.laravel.providers, so Composer will not auto-register anything for Laravel.
• Read in this order: composer.json (type, require, version constraints) → README.md (what "watchdog" actually checks here) → src/*Bundle.php (the bundle class with getContainerExtension()) → DependencyInjection/*Extension.php → Resources/config/services.* → any tests. That tells you whether the useful logic is framework-agnostic or welded to Symfony's container.
• Treat install as an experiment, not a commitment. With 1 star, 0 dependents, and archived status, the realistic first step is composer require raneomik/watchdog-bundle in a throwaway Laravel app to observe dependency resolution. If symfony/framework-bundle gets pulled in, stop — you don't want a second framework in a Laravel app.
• First real use case: identify the single class that performs the "watchdog" check (a health check, heartbeat, or resource guard). That class is the only thing worth keeping. Port it into an Artisan command or a Schedule::call(...) and discard the bundle wiring.
• Check maintenance signals up front: the 2024-09-04 release date plus archived status means no security patches. Fork or vendor-pin before depending on it.

Implementation Patterns

• Symfony-native usage (reference only): register Raneomik\WatchdogBundle\WatchdogBundle in config/bundles.php, add config/packages/watchdog.yaml, and inject the bundle's services into controllers or console commands.
• Laravel wrapper pattern: create a WatchdogServiceProvider that binds the underlying check class as a singleton. Only do this if the class has no Symfony type-hints in its constructor.
• Scheduled monitoring: $schedule->call(fn () => app(Watchdog::class)->check())->everyMinute()->withoutOverlapping(); — the withoutOverlapping() guard matters for any heartbeat/monitor so a slow check doesn't stack.
• Event bridge: if the bundle dispatches Symfony events on failure, add a Laravel listener that forwards them to event() or Log::channel('watchdog')->error(...).
• Health endpoint: expose your own Route::get('/health', ...) that calls the watchdog and returns JSON with a status code. Do not try to reuse the bundle's Symfony controller.
• Config porting: translate the bundle's YAML/XML config into config/watchdog.php and read it with config('watchdog.*') inside your wrapper. Keep the wrapper thin so swapping to a native solution later is a one-file change.
• Prefer native replacements when the logic is trivial: spatie/laravel-health for health checks, Telescope or Sentry for error/uptime monitoring, and plain Cache::remember('heartbeat', ...) for a liveness probe. Writing 30 lines is cheaper than maintaining a bridge.

Gotchas and Tips

• Archived + 1 star + 0 dependents = no support. No Laravel 11/12 compatibility guarantees, no PHP 8.3+ fixes, no CVE response. Audit or fork before production use.
• No package discovery. You must write the service provider yourself and register it in bootstrap/providers.php. If you skip that, app(Watchdog::class) will throw a "target not instantiable" error.
• Dependency conflicts are the likely blocker. Run composer why-not raneomik/watchdog-bundle and composer show -t before installing. Laravel pins specific Symfony component versions; a bundle requiring symfony/framework-bundle will usually conflict or bloat vendor/.
• Container coupling kills portability. Check constructors first for ContainerInterface, EventDispatcherInterface, ParameterBagInterface, or RequestStack. Any of those means the service won't resolve in Laravel's container without shims.
• Config format mismatch. Symfony bundle config is Configuration-tree driven (YAML/XML); Laravel expects a plain PHP array. The translation is manual and easy to get subtly wrong — mirror the defaults explicitly.
• Debugging install/runtime: composer install -vvv, then php artisan about to confirm the provider loaded, then php artisan tinker and app(Watchdog::class) to see the actual resolution error. Wrap each check in Log::debug() so you can see how far it gets.
• Preserve only what's portable. Pure service classes, value objects, and the check logic will survive a port. Anything registered through the bundle's DI extension or Symfony event dispatcher will not.
• Console commands can often be re-registered directly. If the bundle only ships a Symfony command, wrap the same service in an Artisan command instead of trying to run Symfony's console inside Laravel.
• Pin and monitor. If you vendor it, pin the exact tag and add a CI notice for upstream changes — an archived repo can be unarchived or deleted, which silently breaks installs.