Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Including PHPStan Strict as an evaluation dependency has exposed a few issues with code that deserve fixes.
Rather than go through the process of including strict, lets resolve these obvious problems.
Solving these issues before strict is added also allows us to not add items to the baseline.
--
The child issues: fix a bunch of errors reported by PHPStan Strict with all rules disabled, i.e, the "miscellaneous" errors before we can consider introducing strict. Most of the things identified will be easy/sane DX things.
Comments
Comment #2
dpiThere are about 8 or so issues I'll create, one for each error type.
An issue is to come about including PHPStan strict, with all configurable options set to off (the issues resolved here are not configurable).
This will allow us to resolve the strict issues one by one, in a similar manner to PHPStan levels.
The amount of problems exposed by strict is very very large (compared to these sub-issues), and not otherwise covered by PHPStan levels.
Comment #3
dpiComment #4
mondrakeMy 2 cents.
I've just run analysis with level 0 and no baseline - we still have 230+ issues there, over 2 years since the introduction of PHPStan. We discussed to introduce level 2 during the beta window of D11.0, and missed that. No action happened since then, we are in beta window for D11.1 now and will therefore miss that chance here again.
Recently since the addition of the function/method return type check rules (I think they're level 5 or 6 rules, normally), the baseline grew so big that lots of MRs require continuous rebasing to catch up with its changes (can you imagine if we were bumping to level 9 as discussed somewhere else?).
IMHO before looking at adding more rules (phpstan-strict-rules has, btw, 'opinionated' rules, that will require discussion to use or not and possibly have coding standards impacts), we should still work on basics, cleanup existing baseline, bump one level at a time, reiterate. And there's very little focus on that to be honest.
Comment #5
longwaveDo we need the package yet? The docs say that if you turn off all the rules, it still turns on stricter options in PHPStan itself; can't we just turn those on individually where required?
https://phpstan.org/config-reference#stricter-analysis
Comment #6
longwaveComment #7
longwaveFWIW I am in favour of enabling
checkFunctionNameCasebut maybe notcheckExplicitMixedMissingReturnyet, for example.Comment #8
smustgrave commentedI temporarily postponed the 4 child issues, if I'm wrong please let me know. I want to make sure that those changes would be accepted without a rule in place.
Example #3486996: Fix extra periods at the end of comment lines was postponed pending a rule.
Comment #9
dpiRegretfully it seems I havnt made my point about the strict project
I could just as well removal all mentions of the strict project, and these issues would be just as valid.
We don’t need to include or evaluate IF we should use strict. Thats not what these issues are about.
A separate discussion on including strict is necessary, but doesn’t need to get in the way of these handful of things.
There is nothing affecting or distracting any of the existing PHPstan work. The things that strict covers can be worked alongside normal PHPStan levels: all about defensive coding style. Perhaps regarding core PHPStan levels, its worth having discussions in #phpstan about accellerating/resolving your concerns.
Yes, that's it what this batch of issues are addressing. These related issues are not the real strict rules. It’s moreso things that need to be tightened up before the real rules can be applied.
Just looking at the changes in the related issues, they are quite obvious. We don't yet need tooling to enforce them from re-occurring.
And just some 2c, most of my contrib and private projects use strict. From experience, nothing needs to happen with linting ("coding standards/style"). Running strict properly does change the way you write code, for the better, and this isn't something thats enforced by the Drupal Coder notion of linting.
Comment #10
dpiComment #11
dpiI've created #3487646: [meta] Introduce PHPStan Strict Rules for discussion about introducing PHPStan strict rules to Drupal core.
Comment #12
smustgrave commentedGoing to say if these get merged then issues like https://www.drupal.org/project/drupal/issues/3486996 should be unpostponed too
Comment #13
smustgrave commentedAnd just FYI I'm not arguing for or against any of these, but am arguing for consistency. If we postpone issues pending a rule being added then we should do that for all. If we allow these in then any of those issues I believe should be un-postponed and eligible to be merged too.