I'm interested - what's the error formatter you prefer to the default one? Thanks.

This one:

It has the following features:

• No table wrapper, just plain output
• It uses Symfony's Console Hyperlinks together with the %editorUrl% to easily navigate to my preferred editor;
• It truncates long path names (the middle, so first 3 directories and last directory + filename: src/Core/UserBundle/.../GraphQL/UserResolver.php:41);
• Color formatting for fully qualified class names, variables, types, methods and functions to make it easier to quickly understand certain aspects;

final class MyErrorFormatter implements ErrorFormatter
{
    private const FORMAT = "{message}\n↳ <href={editorUrl}>{shortPath}:{line}</>\n";

    public function __construct(
        private RelativePathHelper $relativePathHelper,
        private ?string $editorUrl
    ) {
    }

    public function formatErrors(AnalysisResult $analysisResult, Output $output) : int
    {
        if ($analysisResult->hasErrors() === false) {
            $output->writeLineFormatted('<fg=green;options=bold>No errors</>');
            $output->writeLineFormatted('');

            return 0;
        }

        foreach ($analysisResult->getNotFileSpecificErrors() as $notFileSpecificError) {
            $output->writeLineFormatted(sprintf('<unknown location> %s', $notFileSpecificError));
        }

        foreach ($analysisResult->getFileSpecificErrors() as $fileSpecificError) {
            $absolutePath = $fileSpecificError->getTraitFilePath() ?? $fileSpecificError->getFilePath();

            $message = $fileSpecificError->getMessage();

            // Remove escaped wildcard that breaks coloring
            $message = str_replace('\*', '*', $message);

            // Full Qualified Class Names
            $message = (string) preg_replace(
                "/([A-Z0-9]{1}[A-Za-z0-9_\-]+[\\\]+[A-Z0-9]{1}[A-Za-z0-9_\-\\\]+)/",
                '<fg=yellow>$1</>',
                $message
            );

            // Quoted strings
            $message = (string) preg_replace(
                "/(?<=[\"'])([A-Za-z0-9_\-\\\]+)(?=[\"'])/",
                '<fg=yellow>$1</>',
                $message
            );

            // Variable
            $message = (string) preg_replace(
                "/(?<=[:]{2}|[\s\"\(])([.]{3})?(\\$[A-Za-z0-9_\\-]+)(?=[\s|\"|\)])/",
                '<fg=green>$1$2</>',
                $message
            );

            // Method
            $message = (string) preg_replace(
                '/(?<=[:]{2}|[\s])(\w+\(\))/',
                '<fg=blue>$1</>',
                $message
            );

            // Function
            $message = (string) preg_replace(
                '/(?<=function\s)(\w+)(?=\s)/',
                '<fg=blue>$1</>',
                $message
            );

            // Types
            $message = (string) preg_replace(
                '/(?<=[\s\|])(null|true|false|int|float|bool|string|array|object|mixed|resource|iterable)(?=[:]{2}|[\.\s\|<,]+)/',
                '<fg=magenta>$1</>',
                $message
            );

            $output->writeLineFormatted(
                strtr(
                    self::FORMAT,
                    [
                        '{absolutePath}' => $absolutePath,
                        '{editorUrl}' => str_replace(
                            ['%file%', '%line%'],
                            [$absolutePath, (int) $fileSpecificError->getLine()],
                            $this->editorUrl ?? ''
                        ),
                        '{shortPath}' => $this->trimPath($this->relativePathHelper->getRelativePath($fileSpecificError->getFile())),
                        '{line}' => (int) $fileSpecificError->getLine(),
                        '{message}' => $message,
                        '{identifier}' => $fileSpecificError->getIdentifier(),
                    ]
                )
            );
        }

        $output->writeLineFormatted(sprintf(
            '<bg=red;options=bold>Found %d error%s</>',
            $analysisResult->getTotalErrorsCount(),
            $analysisResult->getTotalErrorsCount() === 1 ? '' : 's'
        ));
        $output->writeLineFormatted('');

        return 1;
    }

    private function trimPath(string $path) : string
    {
        $parts = explode(DIRECTORY_SEPARATOR, $path);
        if (count($parts) < 6) {
            return $path;
        }

        if (str_contains($path, 'in context of class')) {
            return $path;
        }

        return implode(
            DIRECTORY_SEPARATOR,
            [
                ...array_slice($parts, 0, 3),
                '...',
                ...array_slice($parts, -2),
            ]
        );
    }
}

The above formatter is a different approach to solve my previous attempt:

• Clickable line number when using editorUrl #526

After using the new highlighted output for a while, I'm in love. It makes it so much easier to quickly spot the important parts...

I'm now wondering if this can't be part of the core (I want to do the work). If all errors would annotate dynamic parts like variables and type info with Symfony Color Styles.

For example:

sprintf(
  'Method <class>%s</>::<method>%s()</> should return <type>%%s</type> but empty return statement found.',
  $method->getDeclaringClass()->getDisplayName(),
  $method->getName()
),

@ondrejmirtes I'm still using my own error format and I think it's superior to the default. Do you think this PR can be merged (after I rebase + cleanup)?

Hi, I appreciate this and I'd like this because further down the road in PHPStan 1.x I'd like a different default error formatter to try out in bleedingEdge (and maybe make it the default one in 2.0).

To review this PR - $inceptionResult->getProjectConfigArray()['parameters']['errorFormat'] ?? 'table'; isn't the right way to go, you need $inceptionResult->getContainer()->getParameter('errorFormat').

Also - one thing to think about is the behaviour with CI-detected environment. Right now it isn't overriden if the user uses --error-format in CLI. But it'd still be overriden if the user supplied errorFormat in the config which isn't desirable.

So please do not change the error formatter if one is already supplied in the config, to match the current behaviour with --error-format.

Also please change the base to 1.6.x., thanks.

@ondrejmirtes I updated the PR. When --error-format is not specified, it will search for errorFormat parameter, if that is not specified, it will check for CI, or fallback to table instead.

Perfect now, thank you!

BTW I'm definitely interested in improving the default error formatter, and introducing a new file one which we could make the default in 2.0. I really like the one in the screenshot at https://github.com/nunomaduro/collision, so feel free to adapt that code and submit it here as a new file error formatter :)

About the syntax highlighting (totally unrelated to file vs. table formatter, it could be used by both, so it's a separate discussion/feature), the regex approach is too fuzzy for me, I worry it could break in some more complex situations, for example let's say someone has $var key in their array shape, it'd be highlighted wrong.

If all errors would annotate dynamic parts

Yes, it makes sense, but I don't want to break the original message with some Symfony Console-specific tags, because that wouldn't be compatible with other non-console formatters, it's too dangerous to do that.

But - we can attach additional information to RuleError instances created and returned by RuleErrorBuilder. So the call could look something like this:

RuleErrorBuilder::message(sprintf(
    'Method %s::%s() should return %%s but empty return statement found.',
    $method->getDeclaringClass()->getDisplayName(),
    $method->getName(),
))->richMessage(sprintf(
    'Method <class>%s</>::<method>%s()</> should return <type>%%s</type> but empty return statement found.',
    $method->getDeclaringClass()->getDisplayName(),
    $method->getName()
))->build();

WDYT?

Oh, and please update the docs in these places:

• https://phpstan.org/user-guide/output-format
• https://phpstan.org/config-reference#clickable-editor-url

Thank you.

@ondrejmirtes Thanks, I created a PR to document it.

BTW I'm definitely interested in improving the default error formatter, and introducing a new file one which we could make the default in 2.0. I really like the one in the screenshot at https://github.com/nunomaduro/collision, so feel free to adapt that code and submit it here as a new file error formatter :)

Not really sure if I want a formatter like that. Me and my team really like the minimalistic format that we're using for the last months.

If I may suggest: please make the file formatter configurable so that one can toggle the code highlighting part.

About the syntax highlighting (totally unrelated to file vs. table formatter, it could be used by both, so it's a separate discussion/feature), the regex approach is too fuzzy for me, I worry it could break in some more complex situations, for example let's say someone has $var key in their array shape, it'd be highlighted wrong.

Yes, the regex approach is not scalable although it does a really good job. I had to work with what I was getting: raw strings 🙈

But - we can attach additional information to RuleError instances created and returned by RuleErrorBuilder. So the call could look something like this:

RuleErrorBuilder::message(sprintf(
    'Method %s::%s() should return %%s but empty return statement found.',
    $method->getDeclaringClass()->getDisplayName(),
    $method->getName(),
))->richMessage(sprintf(
    'Method <class>%s</>::<method>%s()</> should return <type>%%s</type> but empty return statement found.',
    $method->getDeclaringClass()->getDisplayName(),
    $method->getName()
))->build();

Can't we just scrub all known tags (<class>, <variable> etc) from the error message when the formatter doesn't support rich messages? I think that having to define both error messages is going to be tedious.

Maybe we can start with already adding the named color styles (https://symfony.com/doc/current/console/coloring.html#using-color-styles)? Then it's possible to use them in custom rules already.

Not really sure if I want a formatter like that. Me and my team really like the minimalistic format that we're using for the last months.

Could be a different formatter - something like concise or minimal. The highlighting part could be implemented in all the error formatters except for the machine-readable ones.

Can't we just scrub all known tags (, etc) from the error message when the formatter doesn't support rich messages?

You're just asking for parse issues - someone can have <class> as part of the actual type :) If we start using this, we also need to make sure that the dynamic parts of the error messages are properly escaped (I don't know if Symfony Console actually handles HTML entities correctly).

when the formatter doesn't support rich messages?

We don't know them from the outside so we need a backward-compatible approach.

I think that having to define both error messages is going to be tedious.

Tedious but necessary :)