Pax

When the same config export YAML changes in two branches, merges can become nightmarish especially in display configuration files as the configuration of two fields will meld into each other. In order to avoid this, this module shards those configuration files so there's one YAML per field for each display mode. There will be significantly less conflicts and even when there are some, it'll be trivial to resolve them -- most likely just the weight changing in both branches.

For example, most of the file core.entity_form_display.node.book.default.yml will be sharded into files like core.entity_form_display.node.book.default/content/body.yml, one file for each field. Also if field group is installed then core.entity_form_display.node.book.default/third_party_settings.field_group/group_download.yml shards will be created, one for each group. All in all, four things are sharded currently:

1. The field display configuration, one directory per entity bundle and within each one file per field.
2. The field form display configuration. Same directory/file structure as above.
3. Form groups of the form displays. One directory per entity bundle and within each one file per group -- if there are any groups. If there's no groups, nothing gets created.
4. For fields referencing paragraphs, the "paragraph types for this field" setting. One directory per such field and within each, one file per paragraph type.

This is all done in a file storage class replacement so the rest of Drupal and Drush will not see any differences. The only serious potential problem are tools operating on the files not using Drupal APIs but expecting a Drupal structure (the shards are still YAML files, though) -- these either won't find the shards or won't be able to interpret them correctly. This is enough to make this module not appropriate for core but in practice it shouldn't be a big problem. A smaller problem is how the sync directory will contain a number of subdirectories and under them there can be quite an amount of files. Since no single directory will have a lot of files, I do not consider this a big problem.

Installing the module is required to write shards and the following two lines in settings.php must be added after install to be able to read shards:

require_once 'modules/contrib/pax/src/ShardingFileStorage.php';
class_alias('Drupal\pax\ShardingFileStorage', 'Drupal\Core\Config\FileStorage');

Note these lines can be added before install as well, which can be useful for initial deployment. Shard reading is file driven: if these two lines are in settings.php then whatever shards files are there will be picked up no even if the module is not installed. Shard writing, however requires the module to be installed.