Doctrine annotations analysis

[Zarganwar]

Is it possible to check Doctrine Annotations or exists some extension for it?

[stesie]

What kinds of checks are you thinking of? Yet I'm not aware of another doctrine extension to PHPStan other than this one.

Me and my team actually came up with two ideas: keep @var in sync with the doctrine mapping annotations as well as ensure @JoinColumn annotation explicitly states nullable (as we stumbled over it defaulting to true multiple times). Yet both are less a topic of static code analysis, but more of sniffing for code smells.

Shameless plug: our coding standard for phpcs, which plays nicely with PHPStan (as it happily picks up the @var annotations)

[soullivaneuh]

Some samples:

/**
 * @var \DateTime
 *
 * @ORM\Column(type="date", nullable=true)
 */
private $lastInvoiceDate;

Here, it should be @var \DateTime|null because the column is nullable.

/**
 * @var Product
 *
 * @ORM\ManyToOne(targetEntity="AppBundle\Entity\Product")
 * @ORM\JoinColumn(referencedColumnName="id")
 */
private $product;

Here too, because JoinColumn are nullable by default.

[Majkl578]

I briefly discussed this with @ondrejmirtes and I think this should be split into two parts:

1. generic doctrine annotations support - declaration, attributes, their attributes, project-agnostic with no explicit understanding of their purpose;
2. annotations integration for specific project (ORM, ODM, Symfony Validator, JMS) that would understand their context and usage.

I may try to come up with something in this regard, but I'm not sure if it's not wise to wait for Annotations 2.0 which will come with better parser and PP language definition.

[ondrejmirtes]

Following in #31.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.