Prevent PreExistingConfigurationException by prioritizing features config

Is it possible that features is unable to override the configuration that is provided by Drupal by default on a clean installation?

Yes. If you install attempt to enable a module (features-produced or otherwise) that provides configuration that already exists on the site (whether because it was installed by the Standard install profile or from some other source), you will get an error. This is not an error in Features but a feature of Drupal core.

If you first enable the Features module on the site, you should be able to enable the module despite it re-providing configuration, because Features overrides the relevant core service to enable installation of a feature-type module despite pre-existing configuration. This exception is provided to facilitate the feature development process but is not intended to be used on a site built with a set of features.

If you wish to produce features that can be used to install new sites, you can do so by creating a custom features bundle and selecting to create an install profile for the bundle. This install profile will not include configuration items that are packaged into other features of the bundle (features set).

@grasmash: Thanks for the draft patch. I'd assumed from the original post that you were hitting this error when trying to enable a features module on a site where Features itself was not installed. Features is supposed to already allow you to install feature-type modules despite pre-existing conifguration. We make this exception by overriding (actually, decorating) the config.installer service. Can you confirm? If that's not working for you, we have a bug.

That said, your approach here may be preferable to what we're currently doing, since it doesn't resort to altering an existing service.

defining a dependency on "features" in the feature module is sufficient to workaround this issue. Can we perhaps do that by default with exported features?

In designing Features for Drupal 8, we explicitly decided it would be a tool for developing features, not for installing or supporting them on client sites. See the Principles page in the Features for Drupal 8 handbook:

The module should never be required on any client site in order for the functionality it packages to be available.

The issue you're coming up against is: in my module, how can I reprovide or override configuration that was provided by an other module already installed on the site? This is a generic issue and so beyond the scope of what we're doing in Features.

The easy answer is, put your overrides in the install profile, where overriding configuration is supported. But this isn't always feasible.

For another option, see the Configuration Rewrite module, which provides support for full or partial overrides.

+++ b/src/FeaturesManager.php
@@ -304,8 +304,8 @@ class FeaturesManager implements FeaturesManagerInterface {
-      if (!empty($module_list[$module])) {
-        $extension = $module_list[$module];
+      if (!empty($module_list[$module_name])) {
+        $extension = $module_list[$module_name];

Thanks for catching this bug. I've moved this portion of the patch to a new issue, #2828870: Variable name error in FeaturesManager::loadPackage().

I installed Commerce on site2 but have been setting up Commerce config on site1. I would like to transfer my commerce config from site1 to site2 but when i try to enable my commerce feature on site2 i get a ton of " already exist in active configuration" errors preventing me from installing.

Is this the issue reported here?

Was this not possible in D7 features ("revert")?

Does this patch fix the issue? And if it does.. why has it not been committed in the past 3 years?

hmm.. i think i saw above (or elsewhere) that adding Features as a module dependency would fix this. I didn't understand; but sure enough... once i installed Features on site2 i was able to enable my new feature module (and i guess overwrite existing config). :)

The suggested approach worked for me and I am using it.

I need to re-roll the patch due to following changes:

+++ b/src/FeaturesManager.php
@@ -304,8 +304,8 @@ class FeaturesManager implements FeaturesManagerInterface {
+        $extension = $module_list[$module_name];

This section is already present in the latest 8.x-3.12 release. So patch fails on composer install.

file_scan_directory is deprecated so it isn't present in D9

+++ b/features.module
@@ -54,3 +54,40 @@ function features_modules_installed($modules) {
+  if (file_exists($config_install_dir) && $files = file_scan_directory($config_install_dir, '/^.*\.yml$/i')) {
+    foreach ($files as $file) {
+      // Parse the rewrites and retrieve the original config.

file_scan_directory is deprecated so it isn't present in D9