Configurable fields were ported to the @FieldType Plugin type. They use plugin ID's like text, email, entity_reference. They are then also exposed as typed data plugins as derivatives and are prefixed with field_item:, so e.g. field_item:text, field_item:entity_reference.
For a while, in the Drupal 8 development cycle, base field types (e.g. StringItem, IntegerItem, EntityReferenceItem) were directly exposed as Typed Data (with ID's like string_field, integer_field, entity_reference_field).
To be able to instantiate all field types using the field type plugin manager, base fields need to be exposed as @FieldType plugins too.
The @FieldType plugin definition has therefore been extended with a configurable flag, that allows to register those field types that can't be used as configurable fields in the same way.
All base fields are exposed as @FieldType plugins. To keep base field types apart from configurable field type:
- FieldItems have a configurable = TRUE/FALSE flag, that indicates if they *can* be used to create configurable fields.
- Configurable field type need to implement ConfigFieldIteminterface (and extend from the corresponding base class), they also automatically get the corresponding ConfigFieldItemList list class, while base field type gets FieldItemList list class.
- One base FieldItem could be updated to configurable field type with hook_field_info_alter(), and then the new Item class could serve as both base field and configurable field. See email_field_info_alter()
- All base field types (as long as this field type is not altered to configurable field type) are not available at field UI, while configurable field type's availability depends on the no_ui flag in field type's annotation.