IconType field type silently breaks main-property consumers: declare target_id as the main property
`IconType` declares a single property:
```php
public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition): array {
$properties['target_id'] = DataDefinition::create('string')
->setLabel(new TranslatableMarkup('Icon ID'))
->setRequired(TRUE);
return $properties;
}
```
…but it does not override `mainPropertyName()`, so it inherits `FieldItemBase`'s default of `'value'`, a property that does not exist on this field type. Every API that addresses a field through its main property is silently broken:
- `$entity->set('field_icon', 'pack:icon')` (scalar `setValue()`) writes the `value` to the non-existent value property; `target_id` stays NULL and the value is dropped on save, with no error.
- Generic typed-data consumers that resolve the main property (REST/JSON:API shorthand handling, token/expression systems, etc.) read `NULL`.
- Drupal Canvas (Experience Builder): `StaticPropSource` writes a component prop value into a field item via the main property, so the `ui_icon` field type cannot round-trip a value at all; main-property-targeted dynamic binding expressions evaluate to nothing.
**Steps to reproduce**
```php
$node->set('field_icon', 'phosphor:house');
$node->save();
// $node->get('field_icon')->target_id === NULL — the value was silently lost.
```
**Proposed resolution**
```php
/**
* {@inheritdoc}
*/
public static function mainPropertyName() {
return 'target_id';
}
```
This is the same pattern core uses for single-property field types whose property is not named `value` (e.g. `entity_reference`'s `target_id`).
No BC concerns are apparent: code that already sets values as arrays
(`['target_id' => …]`) is unaffected; code that sets scalars is currently broken and starts working.
issue