Form APIs should not be enforcing generic types that have been rejected in Symfony because of being wrong

Open
#430 10 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
php, symfony
Domain
devtools

Research direction

Start by locating the FormTypeInterface and createForm stubs that define the disputed generic types, then read the linked Symfony discussion and existing extension tests. Done means the rejected generic assumptions are no longer enforced, or their loading is made conditional, with tests covering the chosen behavior.

Written by the indexing model from the issue text.

Description

Generic types for FormTypeInterface and the various createForm methods have been rejected in Symfony because they are lying about the actual behavior of the form component. Those generic types allow to have a nice inferred type for the basic usage of the component, but they will analyze advanced usages of the component in a broken way (reporting errors on valid code, inferring wrong types due to making wrong assumptions about how the component actually works).
See https://github.com/symfony/symfony/pull/40783#issuecomment-942470623 for the discussion when those generic types were submitted upstream.

In version 1.x of the extension, those generic types were configured in skipCheckGenericClasses, which allowed projects to mostly ignore the fact that the extension stubs were adding it. In 2.0x, this is not the case anymore so phpstan will enforce that any form type defines such generic type to satisfy the extension, even when being aware that those generic types are a lie.

My opinion is that those stubs should be removed to match the decision done in Symfony. However, I would also accept a case where the loading of those simplistic generic types is conditional, allowing projects to decide whether they want them (if they rely only on the basic usage pattern where the inference would produce a good result) or not (if they want the analysis to stick to the true behavior of the component).

Dominant language
PHP
Stars
800
Forks
104
Avg merge
4m
Merged PRs (30d)
1

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from phpstan/phpstan-symfony

All issues in phpstan/phpstan-symfony

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.