- What does ayaou/command-logger-bundle actually do?
- It is a Symfony bundle that records every console command execution in a command_log database table. Each record captures the command name, arguments as JSON, start and end times, exit code, error message, and a unique execution token. That gives you an audit trail, execution-time measurements, and a fast way to troubleshoot failed runs.
- Can I use ayaou/command-logger-bundle in a Laravel application with Artisan commands?
- Not out of the box, because it is Symfony-first and depends on the Symfony Console component, Doctrine ORM, and Symfony's event system. It can be adapted to Laravel, but that means replacing Doctrine with Eloquent, swapping Symfony listeners for Artisan::starting and Artisan::finished hooks or a middleware wrapper, and porting the #[CommandLogger] attribute to a Laravel-friendly equivalent. Treat it as a reference implementation rather than a drop-in Laravel package.
- How do I install the Command Logger Bundle with Composer?
- Run composer require ayaou/command-logger-bundle, then register Ayaou\CommandLoggerBundle\AyaouCommandLoggerBundle in config/bundles.php if Symfony Flex does not add it automatically. After that you create config/packages/command_logger.yaml to set enabled, purge_threshold, and the commands list. In a Laravel port you would instead publish a config file and a migration for the command_log table.
- How do I log only specific commands or use wildcards like make:*?
- You have two options: annotate a command class with the #[CommandLogger] attribute, or list command names under the commands key in command_logger.yaml. The config list supports wildcards such as make:*, which is useful for third-party commands you cannot annotate yourself. A Laravel adaptation can mirror this with a config array plus custom matching logic, since Laravel's command resolution does not handle Symfony-style wildcards the same way.
- What information is stored in the command_log table?
- Each row contains commandName, arguments in JSON, startTime, endTime, exitCode, errorMessage, and executionToken. The execution token lets you correlate a single run across logs or reports. Version 1.11.0 optionally adds captured command output, which needs an extra output column and, in Eloquent, an appropriate cast and storage type.
- How does the command-logger:show command help me inspect and filter logs?
- It displays logged executions straight from the command_log table with support for filtering, pagination, and lookup by ID. You can pass arguments and options such as --limit, --code, --id, --error, and --success to narrow results. If you port this to Laravel, recreate it as an Artisan command and add a flag such as --output to render any captured output when present.
- Does the bundle purge old logs automatically, and how do I control retention?
- Yes, the purge_threshold setting defines how many days a log entry is kept before removal, for example 100 to delete anything older than 100 days. Set it low for high-volume environments so the command_log table stays manageable. In a Laravel port, run the equivalent purge as a scheduled Artisan command rather than inside the request path.
- What is the performance overhead of logging every console command in production?
- Every logged command adds database writes plus serialization of arguments, plus optional output capture, which can grow storage fast for verbose commands. Keep output capture opt-in and truncated, and restrict logging to the commands you actually care about instead of logging everything. For high-traffic deployments, consider async writes or disabling capture in production entirely.
- Is the output capture feature added in v1.11.0 safe to enable?
- Only with care, because captured stdout and stderr can contain secrets, tokens, personal data, or internal file paths. Enable capture per command rather than globally, truncate aggressively, and add redaction rules or an allowlist before logging anything. Also make sure a capture failure never interrupts the command itself, and avoid touching interactive or streaming commands.
- How does this bundle compare to alternatives like Laravel Telescope or activity-log packages?
- Telescope and activity-log packages focus on general observability such as requests, queries, jobs, and model changes, while this bundle is narrowly about console command runs and their exit codes and timing. If command auditing is your core need, the bundle's data model is a good template to reimplement with Eloquent and Artisan hooks. If you mainly want broad debugging insight in a Laravel app, a Laravel-native tool will be far less work than porting a Symfony bundle.