hook_install() is invoked before the module's default config is installed during config import

This is not really a bug in my opinion but rather a documentation issue.

The modules own configuration needs to be installed already when the module is installed since it could be settings etc that the module can expect to always exist. The rest of the default config will be synced along with the (potentially changed) modules configuration later in the config sync process. (Modules need to be installed first so that for example plugins are available that are then in the imported config).

We could also defer the default config installation until after the hook is fired (and install first only the simple config as while syncing) then module authors would never attempt to use the default config in the install hook as it would not work there and other solutions would be used.

Unfortunatelly the linked issues have gotten in a different direction and there is still no solution for this issue, which is why I am reopening it.

@bircher has summurized that pretty good:

maybe the confusing part is that through the normal module install the hook is fired after the config/install config is added while during a sync it is the other way around.. since if it had been afterwards also for normal installs you would never have thought that you can "abuse" the hook install for that...

However I do not agree that modules are "abusing" the hook_install, which is documented as follows:

* Perform setup tasks when the module is installed.
 *
 * If the module implements hook_schema(), the database tables will
 * be created before this hook is fired.
 *
 * If the module provides a MODULE.routing.yml or alters routing information
 * these changes will not be available when this hook is fired. If up-to-date
 * router information is required, for example to use \Drupal\Core\Url, then
 * (preferably) use hook_modules_installed() or rebuild the router in the
 * hook_install() implementation.
 *
 * Implementations of this hook are by convention declared in the module's
 * .install file. The implementation can rely on the .module file being loaded.
 * The hook will only be called when a module is installed. The module's schema
 * version will be set to the module's greatest numbered update hook. Because of
 * this, any time a hook_update_N() is added to the module, this function needs
 * to be updated to reflect the current version of the database schema.
 *
 * See the @link https://www.drupal.org/node/146843 Schema API documentation
 * @endlink for details on hook_schema and how database tables are defined.
 *
 * Note that since this function is called from a full bootstrap, all functions
 * (including those in modules enabled by the current page request) are
 * available when this hook is called. Use cases could be displaying a user
 * message, or calling a module function necessary for initial setup, etc.
 *
 * Please be sure that anything added or modified in this function that can
 * be removed during uninstall should be removed with hook_uninstall().

This documentation does not state that all of the module's dependent configuration will be present in hook_install, but it states that anything else will be made ready for the module. Why not the configuration it depends on then? I think that the config import should match the default module install behavior, otherwise any single module realying on that behavior already will be breaking a config import where that module is installed.

Of course we could also agree on the correct behavior to be that hook_install is called only after its simple configuration is installed and before its third-party provided configuration, but that would require the introduction of a new hook that is common for both cases of enabling a module -

1. installing a module in a regular way and
2. installing a module through a config import.

A rewrite of any module out there that that leverages the behavior of a regular module install will be required if a new hook is introduced. On the other side I think it is much more easier to simply delay the hook_install invocation until we can ensure that all the configuration a module is dependent on is available. I cannot currently think of a reason why that would be something we would not want to do. I might be missing something though.

Further we've lost the ability to react on the event that module Z and X have been installed together - e.g. hook_modules_installed will be fired for each module individually during config import instead of together so we have two calls hook_modules_installed([Z]) and hook_modules_installed([X]) during config import versus one call hook_modules_installed([Z, X]) during normal module installation. However I am not sure if this is really a concern we should be thinking about.

For sure we have quite the inconsistency now and no matter which behavior is declared the correct one both approaches of enabling an extension should have the same behavior.

I am attaching a patch proposal showing how hook_install could be delayed to match the normal module installation behavior as much as possible.

I just stumbled on this issue as I am also creating content in hook_install for a custom entity type which has bundles.
The bundles are being created by module configs, which also end up in config/sync.

If the module is installed via a sync, the bundles don't exist when hook_install is called.
I managed to work around this by creating missing bundles in hook_install before creating the entities, but this seems more like a hack.

During a sync, wouldn't it make more sense to:

1. isntall the module and all its configs
2. override the configs with those in config/sync

This would insure that module configs have been imported before calling hook_install, and would likely result in having the production site mimic more closely what usually happens in development.

Here's a re-roll on Gitlab for 11.x based on @hchonov’s patch in #8.

Ran into this too yesterday in https://www.drupal.org/project/automatic_updates. We had to resort to using hook_modules_installed().

Looks like some tests still need to have their expectations updated?

I think it'd be useful if Drupal core had an expanded deployment process built in that could be executed via update.php (or similar) rather than replying on Drush (see #2901418: Add hook_post_config_import_NAME after config import), which is only available when using Drush.