When to create schema while working with config entity? We have a custom form mymoduleForm.php that is used to perform some logic by calling mymodule_preprocess_node(). We were able to add addCacheableDependency() and now the mymodule_preprocess_node hook is able to pull the latest changes even after making several changes and clearing cache. 

We did not create a mymodule.schema.yml as this configuration is not used for translation or any other way then to store some value in the some_field field.

Although it appears to be working just fine without the mymodule.schema.yml file, we were wondering if it is needed. We need some guidance on whether or not this is a situation where the mymodule.schema.yml is needed (or if it always needed).

mymoduleForm.php

class mymoduleForm extends ConfigFormBase {
  public function buildForm(array $form, FormStateInterface $form_state) {
    if (!$this-&gt;entity-&gt;isNew()) {
        \Drupal::service('renderer')-&gt;addCacheableDependency($form, $this-&gt;entity);
      }

    $config = $this-&gt;config('mymodule.settings');

    $form['some_field'] = [
      '#type' =&gt; 'textarea',
      '#title' =&gt; $this-&gt;t('Some field title'),
      '#description' =&gt; $this-&gt;t('some description'),
      '#default_value' =&gt; $config-&gt;get('some_field'),
    ];

    return parent::buildForm($form, $form_state);
  }

  public function submitForm(array &amp;$form, FormStateInterface $form_state) {
    $this-&gt;config('mymodule.settings'),
      -&gt;set('some_field', $form_state-&gt;getValue('some_fields'))
      -&gt;save();
  }
}


mymodule_preprocess_node

function mymodule_preprocess_node(&amp;$variables) {
  $config = \Drupal::config('mymodule.settings');
  // add the cache tag, so that the output gets invalidated when the config is saved
  \Drupal::service('renderer')-&gt;addCacheableDependency($variables, $config);
  $config_value = $config-&gt;get('some_field');

  $library = 'mymodule/some-library';

  if($config_value == 'some_value') {
    $variables['#attached']['library'][] = $library;
  }
}


This is a follow up question from How to clear cache for config entity after making changes?
Short answer: you should always have one, but you can avoid it if you really want (see point 3 below).


  What are schema files used for?
  
  
  The primary use case schema files were introduced for is multilingual support. We need to have a tool to identify all translatable strings in your shipped configuration so when you ship with your own settings as well as default Views, additional user roles, menu items, etc. we can offer those up for translation as part of your module/theme release on http://localize.drupal.org. The nesting levels and types would be enough for this use case.
  We also use schemas to provide actual translation forms for configuration based on your data. This use case is where types gain more importance and labels become crucial. The core Configuration translation module uses schemas to generate translation forms and save translations. The two most important built-in translatable types are 'label' for one-line text input and 'text' for multiline text input.
  Using the knowledge embedded in the configuration schemas about what is stored of a configuration entity, the default persistence implementation for configuration entities requires a configuration schema for the configuration entity, so the right properties are exported with the types defined. Although it is better to provide configuration schemas, if you really don't want, implement the toArray() method in your configuration entity implementation to not require schema for saving configuration entities of your type.
  Last but not least configuration schema is also used to automatically typecast values to their expected types. This ensures that although PHP and web forms in general favor strings over all other types, the right types are used when saving configuration. That is important so when deploying configuration, only actual changes will show up in the difference, no random type changes.
  


From Configuration schema/metadata