[FrameworkBundle] Add a command to dump information of the Symfony Profiler - #64824
#64824[FrameworkBundle] Add a command to dump information of the Symfony Profiler#64824javiereguiluz wants to merge 1 commit intosymfony:8.2symfony/symfony:8.2from javiereguiluz:profiler_commandjaviereguiluz/symfony:profiler_commandCopy head branch name to clipboard
Conversation
1d8838f to
b0b98ec
Compare
|
Thanks for this.
Having a command might not be the most optimized DX, since it requires running the command, and before that, discovering it. |
|
@nicolas-grekas and I actually talked about exactly this in Berlin after my talk, so glad to see it surface here. Just the practical view: I don't see this as command vs MCP. Same profiler data, different transports. One thing worth flagging: a Which is why I'd back Nicolas's first option: a cache warmer / folder where the profile is always written (Markdown and/or JSON) per request. Zero setup, zero discovery (Javier's actual goal), survives a broken container, and gives everyone one stable artifact to build on instead of each reparsing the profiler storage. Happy to help shape the format. Either way, good to see this moving. |
| return Command::SUCCESS; | ||
| } | ||
|
|
||
| public function complete(CompletionInput $input, CompletionSuggestions $suggestions): void |
There was a problem hiding this comment.
Why using the advanced API complete() instead of declaration the suggested value as part of the definition of the input and letting the console component use that info ? There is no fancy logic used for completion here.
| return $this->listProfiles($input, $output, $io, $format); | ||
| } | ||
|
|
||
| $type = $input->getOption('type') ?? 'request'; |
There was a problem hiding this comment.
Instead of this ?? 'request', I would define the non-null default value as part of the option definition (which would also remove the need for [default: "request"] in the description AFAIR, as the console component would be aware of the default)
| return Command::SUCCESS; | ||
| } | ||
|
|
||
| if (!$profiles) { |
There was a problem hiding this comment.
why is having no profiles in the list an error in markdown format but not in JSON format ?
I was recently working on improving the performance of Twig Components in a Symfony application. I was using AI, and the agent could acess Symfony Profiler data via Playwright, but that approach is highly inefficient. Instead, I propose adding a new
profiler:dumpcommand to get Symfony Profiler data programmatically, in either Markdown or JSON format, making it easy to consume from AI agents and other external tools.It works like this:
Use the
--listoption to list the most recent profiles:Why not use an MCP server? Because using a command requires zero setup or maintenance. It's also much faster and works with any external tool, not just MCP-compatible AI tools.