Create a ConfigManager to be able to remove config.inc

+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
@@ -0,0 +1,55 @@
+      return ($config_prefix = $entity_info->getConfigPrefix()) && strpos($name, $config_prefix . '.') === 0;

I know we use this check in other places, but why not switch to return $entity_info->isSubClassOf('\Drupal\Core\Config\ConfigEntityInterface');?

Duh. I misread the snippet. Carry on.

My only worry is that we're provide a wrapper around entity manager, but only one method (getStorageController). It provides a nice place for getEntityTypeIdByName, but it seems like there might be later confusion about whether one should use this or the entity manager directly for getting the storage controller.

1. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
   @@ -0,0 +1,55 @@
   +  function getEntityTypeIdByName($name) {
   
   +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManagerInterface.php
   @@ -0,0 +1,37 @@
   +  function getEntityTypeIdByName($name);
   

   public function

2. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
   @@ -0,0 +1,55 @@
   +   * Returns the entity type of a configuration object.
   +   *
   +   * @param string $name
   +   *   The configuration object name.
   +   *
   +   * @return string|null
   +   *   Either the entity type name, or NULL if none match.
   

   This can be {@inheritdoc} since its on the interface

3. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
   @@ -0,0 +1,55 @@
   + * Definition of Drupal\Core\Config\Entity\ConfigEntityManager.
   

   Contains \Drupal

4. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
   @@ -0,0 +1,55 @@
   +use Drupal\Core\Entity\EntityTypeInterface;
   +
   +
   +/**
   

   Double blank line

5. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityManager.php
   @@ -0,0 +1,55 @@
   +  /**
   +   * @param \Drupal\Core\Entity\EntityManagerInterface $entity_manager
   +   */
   +  public function __construct(EntityManagerInterface $entity_manager) {
   

   Constructs ... and missing the @param description

6. +++ b/core/lib/Drupal/Core/Config/ConfigImporter.php
   @@ -110,24 +94,18 @@ class ConfigImporter {
   -    $this->configFactory = $config_factory;
   ...
   -    $this->uuidService = $uuid_service;
   

   Were these just completely unused? Heh.

Fixed #6

So, this is a good cleanup, but after having read the issue and the patch, I don't understand why it's critical or a beta blocker. I'd propose it as a major beta target/maybe beta deadline instead. We could even provide a deprecation/BC layer after beta, I think; it would just be cleaner not to.

Edit: In the summary, this statement has a false premise:

This blocks beta since it is an API change to the configuration system.

Not all API changes to CMI block beta -- only the critical ones. Non-critical ones (which IMO this is) should be done so the CMI API is stable and pleasant, but we'd release a beta with or without it and tough luck.

Also, re: the change record, we should update it, not delete it, so that there's something for people who ported with config() to find.

+++ b/core/core.services.yml
@@ -70,6 +70,9 @@ services:
     factory_class: Drupal\Core\Config\FileStorageFactory
     factory_method: getActive
+  config.manager:
+    class: Drupal\Core\Config\ConfigManager
+    arguments: ['@entity.manager', '@config.factory', '@config.typed', '@string_translation']
   config.storage:

Agree with the naming, change I found ConfigEntityManager also confusing, given that we're about to introduce ConfigEntityType, where it really is a subclass of EntityType with config specific additions.

Looks great to me.

Applied the patch, and the only remaining functions in there are config_get_storage_names_with_prefix(), config() and config_type(). config.inc still says "This is the API for configuration storage." in the @file declaration, which is obviously bogus.

Wondering if we don't simply want to go ahead and move those three left-over functions to bootstrap.inc or maybe even drop config_typed(), it's used in exactly one location outside of tests. If not that, then maybe an explicit follow-up issue to remove config.inc and delete those functions? The not-deleting of config() for example resulted in new calls to it that were introduced as late as 22. january 14 :( Or move + follow-up?

Works for me, let's do this.

Patch looks great overall, had a few nitpicks:

1. +++ b/core/includes/config.inc
   @@ -70,26 +37,12 @@ function config($name) {
   + * @deprecated as of Drupal 8.0. Use \Drupal::service('config.typed') instead.
   

   Is this really deprecated or are we going to nuke it later?

2. +++ b/core/lib/Drupal/Core/Config/ConfigManager.php
   @@ -0,0 +1,136 @@
   +    require_once DRUPAL_ROOT . '/core/lib/Drupal/Component/Diff/DiffEngine.php';
   

   Could use a @todo on https://drupal.org/node/1848266

+++ b/core/lib/Drupal/Core/Config/ConfigManager.php
@@ -0,0 +1,138 @@
+  public function diff(StorageInterface $source_storage, StorageInterface $target_storage, $name) {
+    // @todo Replace with code that can be autoloaded.
+    //   https://drupal.org/node/2188595
+    require_once DRUPAL_ROOT . '/core/lib/Drupal/Component/Diff/DiffEngine.php';

needs follow-up, point to the issue

@andypost: It already does, that is the follow-up issue?

@Berdir see #19
Patch also fixes doc-block

+++ b/core/lib/Drupal/Core/Config/ConfigManager.php
@@ -50,6 +50,12 @@ class ConfigManager implements ConfigManagerInterface {
+   *   he string translation service.

missed 'T'

Can we please not reuse majors for minor docs cleanups?

Yes please start another issue for that and attach the patch there. It's also hard to tell whether the change notice or the patch is CNR/RTBC.

#2194061: Fix documentation in ConfigSync and other doc follow up.