Voting starts in March for the Drupal Association Board election.
Thanks to the awesome work by @vijaycs85 in, we now have a schema for the configuration files for Field API's $field and $instance config entities.
This schema leverages the "include" mechanism provided by the config schema system, to reflect the fact that certain subtrees in the YML structures (e.g. the content of the 'settings' or 'default_value' entries in field.instance.[entity_type].[bundle].[field_id].yml) depend on the value of another key (in this case, the field type).
This "include" mechanism, however, is purely static : a static schema description shipped by field.module contains the schema for field and instance config structures, and can "include" another static schema snippet, shipped by another module, based on the value of the 'field_type' key in the specific config file whose schema is being generated:
in core/modules/field/config/schema/field.schema.yml: field.instance.*.*.*: (...) settings: type: field.[%parent.field_type].instance_settings in core/modules/text/config/schema/text.schema.yml: field.text_with_summary.instance_settings: type: mapping label: 'Text area with a summary' mapping: text_processing: type: boolean label: 'Text processing' display_summary: type: boolean label: 'Summary input' user_register_form: type: boolean label: 'Display on user registration form.'
When computing the schema for field.instance.node.article.body.yml, (field_type: 'text_with_summary'), this results in the generated schema being expanded into:
(...) settings: type: mapping label: 'Text area with a summary' mapping: text_processing: type: boolean label: 'Text processing' display_summary: type: boolean label: 'Summary input' user_register_form: type: boolean label: 'Display on user registration form.'
and this would be different for field.instance.node.article.field_tags.yml.
The problem is : the list of available settings on a given field type goes through an alter hook.
The 'user_register_form' setting above is altered in by user.module, text.module doesn't know it exists, and cannot be expected to provide schema metadata about it. All the more for settings altered in by contrib modules.
Same applies to widget settings or formatter settings, and most probably to other plugins / "pluggable-not-yet-but-soon-to-be-plugins" subsystems. We have at least two dozen contrib modules relying on alterable settings, and a very vocal @Dave Reid about alterability being a critical feature :).
Not too clear :-/.
Obvious approach would be some syntax that allows runtime code execution to generate config schema snippets :
field.instance.*.*.*: (...) settings: type: "call field_instance_settings_schema([%parent.field_type])" # or more probably some method on some class
could help providing the base code that would make this easily leveraged by all plugin types.
But I think I recall @Gabor in the epicsaying that requiring runtime code execution to generate schemas would make the life of localize.drupal.org impossible.
So, a bit at loss here...
However, with around the corner, the elephant has officially (re-)entered the room :-)