Use required keys of mappings instead of special casing

This looks nice & simple! :D

Do you intend to adopt Mapping::getConditionallyValidKeys() here? Or is that planned for this issue?

You're right that the thing that truly matters to Config Split, is only the required keys. 👍

But … that doesn't mean that some config does not have some invalid keys when merging? IOW: I think that #2 is 99% of the value/work, but I do think that the remaining 1% is also important: validating that the result of merging contains only valid keys.

So I was wrong in #3: you indeed do not need to adopt Mapping::getConditionallyValidKeys(). But AFAICT you do need/want Mapping::getValidKeys(). Although perhaps there is something about the way that Config Split is used that you'd need to do some extremely impractical splitting before you could hit that edge case?

👍

#3401883: Introduce Mapping::getValidKeys(), ::getRequiredKeys() etc. has been committed and will ship in 10.3 🚀

#2 seems to get into issues should the config_split patch attempt to fully remove a mapping from a sequence, say for example: A field defined in an entity_form_display that was hidden. On merging, it would re-add an unconfigured/empty mapping with only the required array properties, which in turn has the form for configuring the display throwing warnings regarding missing `weight` and `type` values.

A bit of investigation, it looks like passing the "parent type" down to know if suppressing the given value as a whole is appropriate might do the trick. Will look into getting an MR together.

Adjusted approach, got MR together with tests around the target functionality.

Ended up removing the behavior added in #3295853: [PP-2] Split config removes settings and third_party_settings, leads to fatal TypeError and moving instead to implement on the "merge" side of things. Tests locally against D10 seem to pass fine; however, those in the pipeline were running against D11, which seems to have diverged in the signature of some of the services in use (Since D10.1: #3284397: ConfigImporter requires the theme extension list to be injected)... made adjustments adjustments to pass the additional service along in the constructor, and things seem to be fine.

Introduction of requiredKeys in 10.3 + this patch has solved issues with keys disappearing on export in certain scenarios denoted above. Changes to the merge behavior should be fine given the internal nature of the class and removal of functionality as noted in #13.

The patch from MR53 no longer seems to apply cleanly to config_split 2.0.2. Needs a re-roll.

I just updated MR. Now the diff file works in version 2.0.2.

#17 looks good.

https://git.drupalcode.org/project/config_split/-/commit/c4d6f474c72f60d... already adds the last patch in the MR, that's why it could not be used as a patch in composer.json

I rebased (or better, merged in master), the patch can now be used in composer.json like this if anyone wants to try:

"drupal/config_split": {
    "Remove empty arrays after config merge": "https://git.drupalcode.org/project/config_split/-/merge_requests/53.diff"
},

It fixes #3547143: Remove empty arrays on removing config patch for me as well.