Add PHPStan analysis

[justlevine]

What problem does this address?

Parallel to efforts in WordPress core, we should consider implementing PHPStan Analysis on the Gutenberg codebase.

Based on the success the Performance team has seen with implementing PHPStan, I would recommend we implement PHPStan regardless (and even to a stricter extent) of what makes it into WordPress core.

What is your proposed solution?

1. Add PHPStan analysis to the codebase.
2. Baseline all existing errors to a TDB level, and enforce that level on new code with CI
3. Independently review and remediate uncovered errors / preexisting tech debt.

[anton-vlasenko]

we should consider implementing PHPStan Analysis on the Gutenberg codebase.

@justlevine I agree 👏.
Ideally, this should happen in perfect parallel, with matching rule levels.
Why matching rule levels?
WordPress Core code is regularly backported into Gutenberg, and vice versa — Gutenberg code is backported into WordPress Core.
Code checked to meet standard level == x, when backported to a stricter codebase (level == x+1), can lead to CI issues and frustration among maintainers.

I'd be interested in helping to enable PHPStan for Gutenberg and can submit a draft PR sometime this month (unless you would like to work on it yourself).

[justlevine]

@justlevine I agree 👏. Ideally, this should happen in perfect parallel, with matching rule levels. Why matching rule levels? WordPress Core code is regularly backported into Gutenberg, and vice versa — Gutenberg code is backported into WordPress Core. Code checked to meet standard level == x, when backported to a stricter codebase (level == x+1), can lead to CI issues and frustration among maintainers.

@anton-vlasenko this is a great point I hadn't considered. Personally, I'd recommend baselining the error until it gets remediated upstream in core, but I'm assuming there's enough preexisting tech debt in Gutenberg alone to keep us busy before an actual decision needs to be made about what PHPStan level gets committed.

I'd be interested in helping to enable PHPStan for Gutenberg and can submit a draft PR sometime this month (unless you would like to work on it yourself).

My plan was to get a draft PR up over the weekend (so I can start remediating errors over the rest of the current mentorship cohort), but I'll likely need help getting the ignoreErrors (vs baselines) and excludePaths correct and would love the help.

[anton-vlasenko]

My plan was to get a draft PR up over the weekend

Great! This works for me.

I'll likely need help getting the ignoreErrors (vs baselines) and excludePaths correct and would love the help.

For excludePaths, you might find it helpful to refer to the phpcs.xml.dist file and the <exclude-pattern> tags, which specify paths that aren't checked by WPCS for various reasons. This could potentially assist with defining similar paths for PHPStan as well.

[justlevine]

Did a first pass over in #66693 . Still need work (e.g. https://github.com/WordPress/gutenberg/pull/66693/files#r1826604652 ), but even already, there's a good amount of unsurfaced errors that can be triaged via the baselines.

[justlevine]

Parallel to this PR, I've begun remediating Level 0 and Level 1 errors over in justlevine#1 and cherry-picking the commits that aren't solely to suppress PHPStan errors into individual PRs (linked to this issue).

The diffs for the baseline/level-*.php show what still needs to be remediated, and I'll be rebasing periodically against trunk so others can work on fixes independently.

[justlevine]

Update: the majority of the level 0-3 issues have been remediated and cherrypicked as PRs onto trunk - sans those related to the _Gutenberg class suffixes used by this plugin vs the non-suffixed classes/methods used in core, and the ones that only make sense in a PHPStan context.

Could use some more feedback/collab on #66693. In the mean time, I'm moving on to any low-hanging fruit in levels 4+