Symfony Command Profile Bundle Laravel Package

Getting Started

• Install with composer require tourze/symfony-command-profile-bundle:^0.1. Treat 0.1.0 as the first tagged release worth pinning to; the notes ship only a compare link, so read 0.0.2...0.1.0 on GitHub before adopting.
• Read composer.json first: the package targets the Symfony Console/Bundle stack (PHP + symfony/console, symfony/framework-bundle constraints), not Laravel's Illuminate\Console API. Confirm the PHP/Symfony version matrix matches your app before installing.
• Then look at src/ for the bundle class and the console event subscriber/listener, and DependencyInjection/ for the config tree (where the output path, enable flag and format are defined).
• First use case: drop it into a Symfony-based service (or a Laravel app that already runs Symfony console components) and time/memory-profile a slow command instead of sprinkling microtime() calls. Register it env-gated to dev/test only.

Implementation Patterns

• Symfony kernel (native path): add the bundle to config/bundles.php guarded by environment, then configure it under its bundle key. Keep it out of prod.
• Laravel bridge: Laravel dispatches Symfony console events, so the cleanest integration is a service provider that binds the bundle's profiler as a singleton and registers a listener on ConsoleEvents::COMMAND / ConsoleEvents::TERMINATE (equivalently Illuminate\Console\Events\CommandStarting/CommandFinished). Avoid trying to auto-discover a Symfony bundle in Laravel — there is no bundle registry.
• Provider skeleton: $this->app->singleton(Profiler::class, ...), then Event::listen(CommandStarting::class, ...) and stop/flush on CommandFinished. Gate on $this->app->environment('local', 'testing').
• Output routing: point the profiler at storage/logs/command-profile.log or a dedicated disk rather than var/ (Symfony default), so artifacts don't collide with Laravel's storage conventions.
• CI pattern: enable it in a CI job and assert on slow-command thresholds; the profiler gives you regression detection for artisan/console commands the same way query-count assertions do for HTTP.
• Composition: if you need custom metrics, decorate the bundle's data collector/service (decorates: in Symfony, $this->app->extend() in Laravel) rather than forking it.

Gotchas and Tips

• 0.x semver: 0.1.0 is a minor bump from 0.0.2 and, under 0.x rules, may contain breaking changes. Read the diff — Tourze packages have historically renamed namespaces/classes between tags. Pin exactly (0.1.*) if you can't absorb churn.
• Symfony assumptions: bundle code commonly reads KernelInterface, %kernel.debug%, %kernel.project_dir% and bundle config parameters. None of these exist in Laravel; expect to supply them manually or bypass the bundle layer entirely and use only the profiler/subscriber classes.
• Event dispatcher identity: the listener only fires if it's registered on the same dispatcher the command runs through. If nothing is logged, verify the dispatcher binding before assuming the package is broken.
• Overhead: profiling hooks add memory and I/O per command. Never enable in production, and be careful with long-running workers (queue:work) — terminate events may not fire as expected, so flush explicitly.
• Nested commands: subcommands invoked from within a command may only be captured at the top level; if you need per-subcommand timings, instrument at the handler level.
• Config caching: after toggling the bundle config, clear caches (php artisan config:clear / cache:clear in Symfony). Stale compiled config is the most common "it's enabled but silent" cause.
• Release hygiene: 0.1.0 has no prose notes, only a changelog URL. Check the compare view for changed class names, config keys, and minimum Symfony/PHP versions before upgrading from 0.0.2; also confirm the license and issue tracker activity, since pre-1.0 Tourze packages vary in maintenance level.