Review and adjust configuration type assignments

Problem/Motivation

We now have several assignment plugins that are configured by default to assign given types of configuration to different features. It's a good time now for a general review.

Note that assignments are only fallbacks. By the time an assignment plugin runs, a given piece of configuration may already have been assigned, and so will be skipped. For example, although 'core' handles field_storage_config, base and namespace both run first, so if there is a node type 'event' and a field storage 'event_date', the storage will be assigned to the event feature rather than core.

Existing assignment plugins, in order of default weight, and their configuration types

• base Creates a feature per bundle or per content entity type. It packages:
  • comment_type
  • node_type
  • user
• core Provides configuration required by other modules. It packages:
  • date_format
  • entity_form_mode
  • entity_view_mode
  • field_storage_config
  • image_style
  • user_role
• site Provides generally useful site configuration. It packages:
  • block_content_type
  • contact_form
  • editor
  • filter_format
  • search_page
  • taxonomy_vocabulary
• profile Provides integrating components specific to the distribution. It packages:
  • block

We also have two additional assignment plugs that are configurable by configuration type.

• exclude Prevents given types of configuration from being packaged.
• optional Designates configuration types to be set as optional (exported to config/optional).

Since a given type of configuration can be assigned or excluded only once, each configuration type should be assigned to a maximum of one plugin. The exception is the optional plugin, which doesn't assign configuration but only marks it as optional; so configuration types can be assigned to optional regardless of whether they've been assigned to a different plugin.

A review should answer the following questions:

• Should any of the configuration types already handled by assignment plugins be removed or moved to a different plugin?
• Of the core-provided configuration types not yet assigned, should any be assigned, and if so to which plugin?
• Should we handle by default any contrib-provided configuration types? If so, which ones?
• Which configuration types, if any, should be marked optional?

Proposed resolution

Unassigned configuration types and their proposed assignments

Simple configuration (system_simple): none
Action (action): site
Base field override (base_field_override): none
Content Language Settings (language_content_settings): profile (in future, possibly a new 'language' plugin)
Entity form display (entity_form_display): none
Entity view display (entity_view_display): none
Field (field_config): none
Language (configurable_language): profile (in future, possibly a new 'language' plugin)
Menu (menu): core
Migration (migration) profile
RDF mapping (rdf_mapping): site
Responsive image style (responsive_image_style): core
Shortcut set (shortcut_set): profile
Tour (tour): profile
View (view): none

Optional configuration in core

At a minimum, we should probably follow core's designation of optional configuration types. Since core doesn't necessarily provide all configuration types that it supports, there may be additional types that should be designated as optional.

In modules

• rdf_mapping
• search_page
• tour
• view

In the standard install profile

• image_style
• responsive_image_style

Additional optional types:

• migration. Rationale: a given feature may provide a migration for e.g. a content type but should not require migrate module to be available.

Remaining tasks