Moving "feeds item" field in form display to non-disabled causes PHP error

Attaching a patch version of my initial work from that fork incase folks want to grab this in such a fashion.

All I did was add a field widget. No display handling. I left a TODO in there to eventually display useful debug information for admins, if that's what even is contained in that field?

This no matter what alleviates fatal errors relating to trying to drag that field into form display though!

@jnicola Thanks for the patch.

This problem makes it impossible to translate form display configurations of entities that have the Feeds Item field.
For more detailed information, I explained in comment #282
#2546212-282: Entity view/form mode formatter/widget settings have no translation UI →

A feeds_item field wasn't mean to appear on the "Manage form display" page

The field type "feeds_item" has a "no_ui" property set to TRUE in its annotation. According to \Drupal\Core\Field\Annotation\FieldType that means:

/**
 * A boolean stating that fields of this type cannot be created through the UI.
 *
 * @var bool
 */
public $no_ui = FALSE;

So I assume this should mean that the field isn't supposed to appear on the "Manage form display" page. Could this perhaps be a bug in Drupal Core? Or did I misunderstood the purpose of the "no_ui" property here?
In Drupal Core, the following field types also have "no_ui" set: "changed", "created", "language", "map", "password", "uri" and "uuid". Some do have a default widget, but not all of them. At least some of these field types I don't see either on "Manage form display", like "uuid". So why is it that an "uuid" field on an entity does not cause trouble, but a "feeds_item" field does?

Commit patch as is?

Anyway, I see that the field is displayed on the "Manage form display". So maybe we should commit this patch as is (if it doesn't break any tests). I wasn't aware that it could cause trouble. Thought it was only a minor UX issue when accidentally dragging the field on the form display.

What a feeds_item field contains

I left a TODO in there to eventually display useful debug information for admins, if that's what even is contained in that field?

A feeds item field contains metadata about the imported entity. It tells when the entity was imported, with which feed entity it was imported and it has a hash value that is used by Feeds to determime if the source item has changed on a subsequent import. The properties "guid" and "url" can be mapped to. Perhaps it is useful to make these two properties editable with a widget.

no_ui property

From what I can see, the no_ui property in the field annotation is only used to prevent this from being listed when creating a new field in entities (/admin/config/people/accounts/fields/add-field).

Field form display configuration

The only way I know to prevent a field from appearing in the form's display list is to define the entity's base fields.
Eg. bellow: Defining the fields of the Feed entity (feeds_feed), if I didn't want the title field to be displayed in the form display setDisplayConfigurable('form', FALSE)
https://git.drupalcode.org/project/feeds/-/blob/8.x-3.x/src/Entity/Feed....

/**
  * {@heritdoc}
  */
public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
  $fields = [];
  ...
  $fields['title'] = BaseFieldDefinition::create('string')
   ->setLabel(t('Title'))
   ->setDescription(t('The title of this feed, always treated as plain text without markup.'))
   ->setRequired(TRUE)
   ->setDefaultValue('')
   ->setSetting('max_length', 255)
   ->setDisplayOptions('display', [
     'label' => 'hidden',
     'type' => 'string',
       'weight' => -5,
     ])
     ->setDisplayOptions('form', [
       'type' => 'string_textfield',
       'weight' => -5,
     ])
     ->setDisplayConfigurable('form', FALSE);
     ...
} 

That being said, it is completely useless in this case...

Feeds item widget

Although I don't see any use case where the feeds item field would be exposed, I think it would be the simplest solution.
Since this field stores internal feed processing information, would it be a good solution to have a readonly option in the widget?

@MegaChriz Thanks for the quick help.