Re-import of "field.storage.*.*" is impossible: the configuration property settings.allowed_values.0.label.0 doesn't exist

Needs tests, if this is a new bug

Sorry, missed that the patch already contains a test

Patch #4 solve the issue with re-importing option field with a list of allowed values.

1. +++ b/core/modules/field/src/Entity/FieldStorageConfig.php
   @@ -7,6 +7,7 @@
   +use Drupal\Core\Field\FieldItemInterface;
   

   This is not actually used in code.

2. +++ b/core/modules/field/src/Entity/FieldStorageConfig.php
   @@ -368,6 +369,11 @@ protected function preSaveUpdated(EntityStorageInterface $storage) {
   +    $this->settings = $field_item_class::storageSettingsToConfigData($this->settings);
   +    $this->settings = $field_item_class::storageSettingsFromConfigData($this->settings);
   

   This looks super weird.

3. +++ b/core/modules/field/src/Entity/FieldStorageConfig.php
   @@ -776,6 +782,9 @@ public function getUniqueStorageIdentifier() {
   +   * @return FieldItemInterface
   +   *   An instance of field item.
   

   This should be a fully qualified class name.

4. +++ b/core/modules/options/tests/src/Kernel/OptionsFieldTest.php
   @@ -97,4 +90,59 @@ function testUpdateAllowedValues() {
   +    $field_storage_config = $this->container->get('config.storage')
   ...
   +    FieldStorageConfig::create($field_storage_config)
   

   The expectation that array passed to create and the stored array in configuration is the same is the problem here. I can see why it exists and it seems sensible but it's not the current behaviour - which we still need to support - otherwise this is an API change.

PHPUnit tests are failing with

InvalidArgumentException: The configuration property settings.allowed_values.0.label.0 doesn't exist.

when I attempt to add additional fields to a custom entity that has list values. The issue seems similar enough to this one to add it here instead of making a new issue. Test passes with this patch.

Re #19 1 and 3 - @BR0kEN our code standards are for fully qualified classnames. And no we don't support use statements just for stuff in documentation.

Re #19 2 - The reason for storageSettingsToConfigData and storageSettingsFromConfigData is because the structure of the options allowed values at runtime can not be stored in YAML files without corruption so we need to change it. YAML is specific about what can go into keys.

Re #19 4 - this is kinda the same as point 2. The values in config don't map exactly to the values on the entity. The assumption that you can read values from configuration and use them to create an entity is not correct.

+++ b/core/modules/options/tests/src/Kernel/OptionsFieldTest.php
@@ -15,16 +15,9 @@
   /**
-   * Modules to enable.
-   *
-   * @var array
-   */
-  public static $modules = array('options');
-
-  /**
    * Test that allowed values can be updated.
    */
-  function testUpdateAllowedValues() {
+  public function testUpdateAllowedValues() {

These are unrelated changes not necessary to fix the bug.

I can confirm this is a bug, and it becomes especially prevalent when using a Features configuration management strategy. Reverting a field storage object for a list field results in this error. I've applied the patch in #27 and the revert works as expected.

Reviewed against core 8.3.7.

+++ b/core/modules/options/tests/src/Kernel/OptionsFieldTest.php
@@ -97,4 +97,59 @@ public function testUpdateAllowedValues() {
+    FieldStorageConfig::create($field_storage_config)
+      ->set('uuid', $this->fieldStorage->uuid())
+      ->enforceIsNew(FALSE)
+      ->save();

This is not how it is supposed to be done. There is a method on the storage called createFromStorageRecord and guessing by #31 features is not using it.

Adding related issue > https://www.drupal.org/project/drupal/issues/2944144