Repository navigation
Quiet formatter output when it isn't going to a terminal #1544
Description
Activity
- changed the title
[-]`extension validate` reports 0 problems when all findings are suppressed, with no indication of suppression[/-][+]Quieten formatter output when it isn't going to a terminal[/+]on Sep 11, 2026 - changed the title
[-]Quieten formatter output when it isn't going to a terminal[/-][+]Quiet formatter output when it isn't going to a terminal[/+]on Sep 11, 2026 Soner (@shyim) Do you think it's a good candidate for Pascal's first issue?
Reacted by somethingsnot really like an easy easy ticket tbh fiddly, but fine
Tomasz Turkowski (@tturkowski) to do some digging for Pascal to take over
Just a thought: instead of stripping things out when "the output isn't going to a terminal", it might be a better idea to already think ahead and properly parse each formatters output into a struct we own in the shopware-cli, similar to what the extension / project validate command does.
Then we can also "own" the terminal and other output formats and change them how we would like.
Malte Janz (@MalteJanz) Sure, makes sense
I had trouble and not all tools supported that, thats why I gave up captureing their content...
Reacted by Malte JanzPHP tools often don't provide the parsing. Could check the tools that don't have it, consider making an upstream PR. If it's just one tool, why not?
At least worth the effort of looking into it and writing it down.
I verified each formatter tool’s output options and behavior so we can decide how we want to handle them.
Generally, silencing can be achieved by simply not routing the commands’
stderrtoos.Stderr.
Parsing the output to generate results is a bit more complex, as described below.PHP-CS-Fixer
- Result: stdout
- Diagnostics: stderr
- Output options
--show-progress:nonehides progress completely.dotsoutputs progress similar to PHPUnit instead of showing a progress bar, which is also a useful option.--format: Multiple formats are available. For our use case,jsonfits best.--verbose: Shows the applied fixers.--diff: Includes a diff in the output, which can help us pinpoint the actual location of the issue.- Use exit codes to determine whether an error occurred.
Suggestion
Use JSON as the output format and set progress to either
dotsornone. Run with--verboseso we can show which rules were violated.We must consider exit codes when handling errors. Errors are not included in the structured output and are written to stderr.
If we want richer support, such as annotations in PRs, we may want to parse
--diff. However, we still won’t be able to identify the exact rule violation for each line. Therefore, I think adding a single annotation to the first line of each affected file, prompting the user to run PHP-CS-Fixer without--dry-run, would be a good solution.JSON Schema: PHP-CS-Fixer JSON Schema
Prettier
- Result: stdout
- Diagnostics: stderr
- Output options
--list-different: Outputs a list of files that need formatting to stdout, one file per line.- Use exit codes to determine whether an error occurred.
Suggestion
Unfortunately, Prettier does not seem to provide more detailed output than the list of affected files. The only way to generate a more detailed report would be to inspect the diff from an actual run with
--write, which we should avoid during a dry run.There are other possible workarounds, such as using
stdin, but they would result in poor performance and more complex parsing.We must consider exit codes when handling errors. Errors are written to stderr.
I'd handle this like PHP-CS-Fixer, but without any details on the rule violations.
Reacted by somethingsPascal Zarrad (@pascal-zarrad) A quick thanks for the nicely detailed comment above :)
extension formatprints each underlying tool's raw output, including things that only make sense on a live terminal. Every run shows PHP-CS-Fixer's version banner, runtime line, config path, core count and a "ask for help" URL, plus an animated progress bar (0/2 … 2/2). This shows up even when the output is redirected to a file or piped into something else, where there's nothing to animate. Logs and CI output fill up with progress-bar frames and banner text. A run that changes nothing still prints around 15 lines.Suggested improvement
When the output isn't going to a terminal, drop the progress bar and the tool banners and keep just the result lines (which files changed). The banners could stay available under
--verbosefor debugging. A clean run should be nearly silent.Example — a no-op run that changed nothing:
Related to #1528, but scoped to the mechanical part that can be done without the broader output-normalization design.