coverage: 94.758% (+0.01%) from 94.748%
when pulling 4636f58 on gharlan:phpstan-baseline-per-identifier
into d853dad on PHP-CS-Fixer:master.

I have no strong opinion about the split. I think @keradus needs to decide.

@Wirone, I'm sure you remember why we chose PHP baseline over NEON?

PHP format of PHPStan baseline offers IDE navigation when you click on the filename, as far as I remember that's the main advantage.

I am not sure if this PR brings real value. I like Shipmonk's tools, but this one seems like an overhead without much gain. Personally I don't need splitting by issue type, as I rather don't work on fixing by type, rather by file (multiple issues in the same file and files related to it). It's an additional dependency, complicated process of dumping baseline, and information spread across multiple files.

In GetResponse I created a process for splitting baseline by area, which makes more sense IMHO (well, depending on the context obviously). Thanks to that, each dev team could work on their issues easier, as they have them extracted into separate files, located in specific spaces (with ownership). That, IMHO, had real value. Splitting by issue type does not necessarily give anything like that, at least from my perspective.

But I won't insist on that, if @keradus and @kubawerlos like it more, then let's do it. Personally I just don't need it.

PHP format of PHPStan baseline offers IDE navigation when you click on the filename, as far as I remember that's the main advantage.

I prefer php baseline for the same reason 👍
(when I need the baseline I always use split php files)

Personally I don't need splitting by issue type, as I rather don't work on fixing by type, rather by file (multiple issues in the same file and files related to it).

I do both. Sometimes I work on fixing a specific kind of issue, sometimes I try to solve the issues in a specific file.

(I have a draft branch locally for shipmonk/phpstan-baseline-per-identifier which would group the errors per file inside the type baseline files. But it is not finished and not sure if they want that feature.
But still I would prefer to group by type first.)

I like the overview of the error types and how many errors there are in each case.
I also like the fact that if you accidentally include an atypical error in the baseline, it is even more noticeable because a new file is created for it.
And yes, usually the baseline should shrink only. But especially when refactoring the code, the baseline errors also change etc.

Personally, it also motivates me when I see an error type that I can possibly resolve completely and the associated baseline file then disappears (like the one foreach.nonIterable error was resolved in the static-var pull request, see my previous "update baseline" commit).

But I also understand your reasons. And of course there's no problem if you decide against it.

for me it's more important to shrink the baseline than to consider which format for it to use

My experience is that this happens faster with the split files. Because it is much more motivating to be able to delete entire baseline files than to eliminate a few errors from a huge file.

I will think about your feedback, thanks @gharlan 👍.