Define entities and fields as universalObjectCratesClasses?

[mfb]

Bug report

Entities and fields have magic getters and setters allowing them to store basically any property. This is used in core, for example adding a _referringItem property to an entity when it's referenced, and adding multiple database columns to a field.

So arguably, entity and field base classes/interfaces should be added to a universalObjectCratesClasses list? These would be Drupal\Core\Entity\EntityBase, Drupal\Core\Entity\EntityInterface (useful since variables/arguments are often typed to an interface), Drupal\Core\Field\FieldItemBase, Drupal\Core\Field\FieldItemInterface

Code snippet that reproduces the problem

Didn't make a code snippet yet but I could.

[mglaman]

Picking this up. #1048 was filed for the same symptom without noticing this issue, and #1053 implements the narrowest slice: Drupal\Core\Entity\ContentEntityInterface is added to universalObjectCratesClasses. That opens PHPStan's dynamic-property gate for the interface and everything extending it, so $entity->field_foo works on a value typed ContentEntityInterface or NodeInterface, and @property tags declared on those interfaces start resolving too.

On the other entries proposed here, checked against core source:

• EntityInterface: defensible on 11.2 and later. EntityBase implements __get() and __set() for any name there, and ConfigEntityBase carries #[AllowDynamicProperties], so config entities are crates at runtime. On 10.4 the base class has no magic methods, so listing the interface would claim more than the runtime does on that version.
• EntityBase and FieldItemBase: redundant. Both declare __get(), so PHPStan already allows dynamic properties on them and their subclasses.
• FieldItemInterface: also redundant for the gate. Core's interface declares __get(), __set(), and __isset() itself. Whether $item->anything resolves is a question of which reflection extension answers, not of the crate list.

Proposal: this issue tracks the EntityInterface decision and the _referringItem case from the description as a fixture. #1053 stays scoped to ContentEntityInterface, where the runtime behavior is the same on every supported core version.