rcsofttech/console-profiler-bundle
Console Profiler Bundle adds a Symfony web profiler panel for console commands, capturing arguments, input, output, execution time, memory usage, and exceptions. Inspect CLI command runs directly in the profiler to debug performance and failures faster.
Architecture fit. The package is a Symfony Bundle, not a Laravel package. That distinction is the single most important finding in this evaluation: bundles are wired into an application through Kernel::registerBundles(), a bundle class extending Symfony\Component\HttpKernel\Bundle\Bundle, and a DI extension that loads a service container config and config tree. Laravel has no equivalent registration path. The parts that are portable are the underlying hooks — Laravel's Artisan is built on symfony/console, so the ConsoleEvents::COMMAND / INITIALIZE / TERMINATE events, command instances, and InputInterface/OutputInterface all exist in a Laravel app. Whether the package can be leveraged therefore reduces to a single question: is the useful behavior in the event subscribers (portable) or in the bundle bootstrapping/DI layer (not portable)? A source read should answer this before any sprint time is committed.
Integration feasibility. Plausible but not turnkey. A viable path exists — register the package's event subscribers manually in a Laravel service provider, or wrap the whole thing behind a bespoke artisan dev:profile command that constructs the profiler explicitly — but this is an integration shim we would own, not a composer require and go. Two known friction points beyond registration: the auto-refreshing TUI likely assumes a raw, TTY-attached terminal and may conflict with Laravel's output decorators, Prompts, progress bars, and the --no-interaction flag; and any refresh loop that runs during command execution can deadlock the command lifecycle if it does not exit cleanly on failure or signal.
Technical risk. High for a dev tool. Signals: 16 stars, 0 dependents, a single maintainer, and no evidence of production usage anywhere — the 9.0 composite score reflects intrinsic code quality, not adoption or durability. This is effectively an unproven pre-1.0 dependency. TUI rendering is also inherently brittle across Windows terminals, CI runners, and Docker containers without a TTY, and a profiler dashboard that surfaces command arguments, environment variables, or connection strings is a low-grade secrets-exposure surface if it is ever accidentally enabled outside local.
Key questions.
symfony/framework-bundle, or only the console component?Stack fit. Clean for Symfony shops; indirect for Laravel. Given we are evaluating this against Laravel/PHP, the honest framing to stakeholders is "a Symfony-native tool we can probably shim into Artisan." Worth doing only if the team's pain is specifically debugging long-running or interactive Artisan commands — for that narrow job, a live view is genuinely better than -vvv log spelunking. If the need is general observability, Laravel Telescope and Xdebug already cover it and are supported.
Migration path. Additive and dev-only, so there is no migration. composer require --dev, gated behind APP_ENV=local in a service provider so it never loads in staging or production. No data model, no schema, no runtime dependency for application code. The exit ramp is composer remove plus deleting one provider.
Compatibility. Pin exact versions and verify against our PHP and Illuminate/Console versions before writing any shim code. Confirm the Symfony Console major version aligns with what Laravel ships — a mismatch here silently breaks event dispatch. Treat any upstream release as potentially breaking until a 1.x is published.
Sequencing.
dev:profile command rather than letting developers invoke the vendor surface directly. That gives us a swap point if the package is abandoned and keeps the shim in one file.Maintenance. Bus factor of one. With zero dependents there is no community backstop: no fork ecosystem, no Stack Overflow corpus, no third-party patches. If the maintainer stops, we own it. Budget either a fork-and-vendor arrangement or an explicit acceptance that this is disposable tooling we will rip out rather than fix.
Support. No SLA, community-only, and the failure modes (garbled terminal output, hangs in CI) will present as our developer-experience bugs to the team, not as vendor bugs. Whoever integrates it becomes the de facto support contact. Name that person.
Scaling. Runtime scaling is a non-issue — it is a per-process developer tool with no shared backend and no production footprint when gated. The relevant scaling limits are organizational: each concurrent Artisan run spins its own dashboard, there is no aggregation across services or machines, and it does nothing for CI or ephemeral containerized environments where nobody is watching a terminal.
Failure modes. Terminal incompatibility on Windows and in no-TTY containers; output corruption when interleaved with prompts or progress bars; memory growth in long commands held open by the refresh loop; hangs or orphaned processes if the loop does not terminate on command exception or SIGINT; credential exposure in the dashboard; silent breakage on the next Laravel or Symfony Console upgrade. Each needs a documented fallback, and the gating in local only is the primary control.
Ramp-up. Low for consumers — it is a read-only dashboard, and a developer understands it in minutes. The cost sits with the integrator: the service-provider shim, the env gating, and the terminal-compatibility workarounds are non-obvious knowledge held by one or two people. Estimate roughly one day for the POC and three to five days for a hardened, gated, documented internal wrapper. Document the shim alongside the decision record, or the next person to hit a terminal bug will not know why the code exists.
How can I help you explore Laravel packages today?