Provide stub files for field types in core provided optional modules

[dpi]

#342 #344 added stubs for field types which are always available with Drupal.

It'd be great if field types in Drupal in optional [non-test] modules were also hinted

eg

text.module:

\Drupal\text\Plugin\Field\FieldType\TextWithSummaryItem \Drupal\text\Plugin\Field\FieldType\TextItem \Drupal\text\Plugin\Field\FieldType\TextLongItem

options.module:

\Drupal\options\Plugin\Field\FieldType\ListStringItem \Drupal\options\Plugin\Field\FieldType\ListIntegerItem \Drupal\options\Plugin\Field\FieldType\ListFloatItem

etc, etc

For writing field type stubs, see the examples:

• https://github.com/mglaman/phpstan-drupal/tree/main/stubs/Drupal/Core/Field/Plugin/Field/FieldType
• https://github.com/mglaman/phpstan-drupal/tree/main/stubs/Drupal/file/Plugin/Field/FieldType
• https://github.com/mglaman/phpstan-drupal/tree/main/stubs/Drupal/link

Official docs: https://phpstan.org/user-guide/stub-files

[mglaman]

Yes, it was such a drag creating these. Especially the first few due to needing to stub all dependent classes or interface. My plan is to add these, I just need to sit down and do it. Or make issues for them all as "good first issue"

[mglaman]

I'll work on making issues based on this format https://github.com/mglaman/phpstan-drupal/issues/360

[mglaman]

Layout Builder isn't needed since it has a @property doc already

[mglaman]

@dpi do you think we should add some common contrib field types? Like Entity Reference Revisions?

[dpi]

It'd be nice, sure, but how sustainable is it? I personally wouldnt want to maintain an unlimited number of contrib types? Maybe contribs should implement @property. As you already mentioned LB has it. Theoretically contrib modules are more agile, and we can always point them here, or to some documentation on what they need to do.

[dpi]

I think its critical that this project provides the shims for core, even if the ultimate aim would be to create issues in core itself to add hints.