Logging Bundle Laravel Package

Getting Started

The first thing to internalize: this is a Symfony bundle, not a Laravel package. Despite the generic "logging" name, vysokeskoly/logging-bundle is designed to be registered in a Symfony config/bundles.php and configured under a bundle-specific key in config/packages/*.yaml. It has no Illuminate\Support\ServiceProvider, no extra.laravel entry in composer.json, and Laravel's package auto-discovery will not touch it.

Minimal steps to evaluate whether it's worth pulling in:

composer require vysokeskoly/logging-bundle
composer show vysokeskoly/logging-bundle   # check last release / abandoned flag

Look first at:

1. The bundle's DependencyInjection/*Extension.php and DependencyInjection/Configuration.php — these tell you exactly which handlers/processors/formatters the bundle wires up and what options exist. In a Symfony bundle this is the entire "API surface."
2. The README.md for the config tree it expects.
3. Whether any of the handler/formatter classes are standalone (usable without the container), because that's the only realistic path to reuse in Laravel.

Your first real use case in a Laravel codebase is almost certainly not this package. It's a custom Monolog channel in config/logging.php:

'channels' => [
    'audit' => [
        'driver' => 'monolog',
        'handler' => Monolog\Handler\StreamHandler::class,
        'with' => ['stream' => storage_path('logs/audit.log')],
        'tap' => [App\Logging\AuditFormatter::class],
    ],
],

Use the bundle only if you're maintaining a Symfony app, or bridging a legacy Symfony component into a Laravel service.

Implementation Patterns

Because this is a container-driven bundle, the intended usage pattern is configuration over code — you register the bundle and declare handlers in YAML/XML. There is no fluent API you'd call from a controller or job.

The realistic ways a Laravel developer ends up here:

1. Symfony coexistence. If your Laravel app shares code with a Symfony service (e.g. an HTTP client or legacy domain layer), and the shared piece relies on this bundle's handlers, keep the bundle in the Symfony app and let Laravel write to its own Monolog channels. Do not try to boot a Symfony bundle inside Laravel's container — it requires a full Kernel, ContainerBuilder, and parameter bag that Laravel does not provide.

2. Extract and re-wrap. Inspect the bundle's handler/formatter classes. If any of them implement Monolog\Handler\HandlerInterface (which is framework-agnostic), you can register them directly in a Laravel channel:

'tap' => [App\Logging\RegisterBundleHandlers::class],

where the tap class uses $logger->pushHandler(new \Vysokeskoly\LoggingBundle\Handler\SomeHandler(...)). This bypasses the bundle wiring entirely and is the only clean integration point.

3. Configuration translation. Any YAML options exposed by the bundle's Configuration.php map 1:1 onto constructor arguments of the underlying Monolog handlers. Translate them to the 'with' array in config/logging.php.

4. Workflow for evaluation. Create a throwaway Symfony skeleton (composer create-project symfony/skeleton), install the bundle, and enable/disable the features you care about. That's the fastest way to understand what it actually adds — the docs are minimal and there are no dependents (0 on Packagist) to crib from.

Gotchas and Tips

• No Laravel auto-discovery. composer require will succeed, but nothing registers. Expect Class not found or silent no-ops until you understand you're outside the intended framework.
• Unmaintained. Last release 2022-07-18, zero stars, zero dependents. Assume no security patches and no compatibility work for newer Monolog majors (Monolog 2 → 3 changed several handler signatures). Pin Monolog explicitly and audit composer why-not before relying on it.
• Symfony version coupling. A 2022 bundle will likely assume Symfony 5.x/6.0 container internals (TreeBuilder, load(), parameter resolution). If you're on Symfony 6.3+/7.x, test extension loading carefully; deprecated ContainerBuilder calls can break silently.
• Configuration tree strictness. Symfony bundles reject unknown config keys via TreeBuilder. Typos in YAML throw at container compile time, not runtime — so a "logging doesn't work" issue is usually a config/packages key mismatch, not a handler problem. Run bin/console debug:config vysokeskoly_logging (or the bundle's actual alias) to see resolved config.
• Debugging in Laravel. If you're evaluating the extracted-handler route, use php artisan about to confirm channel drivers, php artisan config:clear, and write to a scratch channel to verify the handler fires before wiring it into production logging.
• Extension points. The genuine value in a bundle like this is Monolog processors (adding context to every record) rather than handlers. Processors are plain Monolog classes and port to Laravel cleanly — check vendor/vysokeskoly/logging-bundle/ for anything implementing ProcessorInterface before dismissing the package wholesale.
• Don't fork-and-pray. With 0 stars, filing issues is unlikely to yield fixes. If you need the behavior, vendor the specific class into app/Logging/ with attribution under MIT rather than depending on the package.