>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618612. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !401 >>> <p>The phpstan job runs at level 0. This project ships no phpstan configuration, so CI fetches the Drupal Association default asset, which sets <code class="language-php">level: 0</code>, and <code class="language-php">_PHPSTAN_LEVEL</code> is not set either. The job log confirms it: <code class="language-php">phpstan analyze .</code> is invoked with no <code class="language-php">--level</code> at all. At that level almost nothing is checked, so a wrong type reaches CI unnoticed.</p> <p>Level 3 is reachable here, and the domain project shows how. Its 4.x branch runs a project <code class="language-php">phpstan.neon</code> at <code class="language-php">level: 3</code> with two companions: an <code class="language-php">entity_mapping.neon</code> that tells phpstan-drupal which concrete class each entity type id loads as, and a <code class="language-php">phpstan-baseline.neon</code> holding the five leftovers. The mapping is what makes the level affordable, because without it every <code class="language-php">$storage-&amp;gt;load()</code> is an <code class="language-php">EntityInterface</code> and every concrete method call on it is reported.</p> <h3>Measured on this module</h3> <p>Against Drupal 11.3.16, over <code class="language-php">src</code>, <code class="language-php">modules</code> and <code class="language-php">tests</code>:</p> <ul> <li>level 3 with no entity mapping: 448 findings.</li> <li>level 3 with a mapping for orchestra's eleven entity types: 178 findings, 31 of them in <code class="language-php">src</code> and 147 in tests.</li> </ul> <p>So the mapping alone removes 270 of them, and what is left is small enough to fix rather than baseline.</p> <h3>The 31 in src</h3> <p>17 distinct messages across 23 files: 20 <code class="language-php">method.notFound</code>, 6 <code class="language-php">return.type</code>, 2 <code class="language-php">property.nonObject</code>, and one each of <code class="language-php">property.notFound</code>, <code class="language-php">parameterByRef.type</code> and <code class="language-php">method.childReturnType</code>. They look like genuine typing bugs rather than noise. A sample:</p> <ul> <li><code class="language-php">PluginFormInterface::getConfiguration()</code> called on a plugin form in <code class="language-php">InnerPluginSettingsTrait</code>, <code class="language-php">InteractionPluginConfigTrait</code> and <code class="language-php">OrchestraCmForm</code>: the interface does not declare it, so the call depends on the plugin also being <code class="language-php">ConfigurableInterface</code>.</li> <li><code class="language-php">FormInterface::getEntity()</code> in <code class="language-php">DomainTenantHook</code> and <code class="language-php">ConsumerTenantHook</code>, same shape: the form has to be an <code class="language-php">EntityFormInterface</code> for that to hold.</li> <li>Two Views field plugins, <code class="language-php">InstanceReference</code> and <code class="language-php">InstanceTraceLink</code>, whose <code class="language-php">render()</code> returns a render array where the signature promises <code class="language-php">MarkupInterface|string</code>.</li> <li><code class="language-php">DelegationForm::validateForm()</code> declares <code class="language-php">void</code> against <code class="language-php">ContentEntityFormInterface::validateForm()</code>.</li> <li><code class="language-php">AdvanceQueueDrainer</code> and <code class="language-php">OrchestraUiController</code> read <code class="language-php">-&amp;gt;data</code> off <code class="language-php">claimItem()</code>, which core documents as <code class="language-php">object|bool</code>.</li> </ul> <h3>The 147 in tests</h3> <p>106 of them are one pattern, <code class="language-php">property.nonObject</code>, from reading a property off a <code class="language-php">json_decode()</code> result typed <code class="language-php">object|true</code>. A single decode helper that asserts the shape would settle most of them at once.</p> <h3>Scope</h3> <p>This is not a Drupal 12 matter. The next-major phpstan job is green today, because the deprecation rules that decide forward compatibility run at every level; see <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/orchestra/-/work_items/3618602" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/orchestra/-/work_items/3618602</a></span>, which declared Drupal 12 support and left this untouched on purpose so the compatibility change stayed reviewable.</p> <p>Proposed: add <code class="language-php">phpstan.neon</code> at level 3 with an <code class="language-php">entity_mapping.neon</code> beside it, then fix the findings rather than baseline them. If any genuinely cannot be fixed, a baseline entry for those should be agreed here first rather than added quietly.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to take the measurements it quotes. I reviewed them; no code change is proposed yet.)</p>