Remove SchemaStorage

+++ b/core/lib/Drupal/Core/Config/InstallStorage.php
@@ -137,6 +138,24 @@
+  protected function getCoreComponents() {
+    $extension = '.' . $this->getFileExtension();
+    $folders = array();
+    $directory = DRUPAL_ROOT . '/core/' . $this->folderToScan;
+    $files = new \GlobIterator($directory . '/*' . $extension);
+    foreach ($files as $file) {
+      $folders[$file->getBasename($extension)] = $directory;
+    }
+    return $folders;
+  }

Can a config/schema directory have subdirectories?

Thus far, I assumed we'd only support files in that directory, not further subdirectories?

In other words, I expected this to simply be:

return array(
  'core' => DRUPAL_ROOT . '/core/' . $this->folderToScan;
);

?

If we'd additionally do the change in attached patch, then we could simply use getComponentNames('core', 'core') as is? :)

The proposal in #5 is also part of the architectural proposal in the new extension system meta.

Created concrete proposal + patch for #5 now:

#2228921: Consolidate system.module + system.theme + system.theme.disabled into core.extension config

That change has landed, so this patch gets much simpler now :-)

Re-rolled against HEAD, and:

1. Removed obsolete getCoreComponents() method.
2. Reverted faulty removal of variable initialization in TypedConfigManager::getDefinitions().
3. Renamed $folderToScan to $collection → identical change as in #2190723: Add a KeyValueStore\FileStorage to replace e.g. ConfigStorage

Removed obsolete TestSchemaStorage.

10: schema.storage.10.patch queued for re-testing.

Looks great, I just found two minor coding style issues. Certainly makes sense, it's a somewhat similar pattern as the language override storage, that also makes storage folder configurable and even allows to change it.

Agree with $collection being a strange name, +1 to directory. As those storages are explicitly about scanning module config directories, they will never be related to key value collections...

Also +1 to to remove controller, we already have a separate issue to remove it everywhere but when we touch it anyway...

1. +++ b/core/lib/Drupal/Core/Config/InstallStorage.php
   @@ -30,9 +30,21 @@ class InstallStorage extends FileStorage {
       * Overrides Drupal\Core\Config\FileStorage::__construct().
   

   Can we fix the line her as well? Should be something like Constructs a X object, we can't do @inheritdoc if we extend it.

2. +++ b/core/lib/Drupal/Core/Config/InstallStorage.php
   @@ -65,12 +77,19 @@ public function getFilePath($name) {
   +   * Implements \Drupal\Core\Config\StorageInterface::exists().
   +   */
   +  public function exists($name) {
   +    return array_key_exists($name, $this->getAllFolders());
   +  }
   

   @inheritdoc.

   getAllFolders() is a very confusing method name, assumed that it returns folders, but it returns an array keyed by configuration files with the folder as value.

   Not related to this issue.

3. +++ b/core/modules/locale/lib/Drupal/locale/Tests/LocaleConfigManagerTest.php
   @@ -40,18 +40,13 @@ public static function getInfo() {
        $language = new Language(array('id' => 'de'));
   -    $this->assertFalse($locale_config_manager->hasTranslation('locale_test.no_translation', $language), 'There is no translation for locale_test.no_translation configuration.');
   -    $this->assertTrue($locale_config_manager->hasTranslation('locale_test.translation', $language), 'There is a translation for locale_test.translation configuration.');
   +    $result = $locale_config_manager->hasTranslation('locale_test.no_translation', $language);
   +    $this->assertFalse($result, 'There is no translation for locale_test.no_translation configuration.');
   +
   +    $result = $locale_config_manager->hasTranslation('locale_test.translation', $language);
   +    $this->assertTrue($result, 'There is a translation for locale_test.translation configuration.');
   

   Just wondering if there's an actual change on those lines or just making them better readable? Because I don't see a change :)

Thanks, this looks good now I think.

@alexpott and I shortly discussed folder vs directory and it looks like folder is more used as an UI term in windows/osx and the only place where we used folder right now, is the getAllFolders() method and the related $this->folders property, for which @alexpott already opened an issue to rename it to something better.

I assume this will pass, so RTBC.

Committed/pushed to 8.x, thanks!