Notes on the subtle interplay between optional configuration and config actions

Or maybe they don’t work together at all.

Optional configuration provided by modules and themes should be stored in config/optional.

But that applies only to full pieces of configuration. There are other situations, especially permissions, where what is optional has to be a small piece of a configuration entity.

According to the response to this request to test for dependency, config actions will just silently fail if they lack dependencies.

But per Skip actions that won’t apply

Also related, also from Nedjo, Support altering optional configuration.

Use case

We add a new feature that has a new role, that shouldn’t be there if a siteholder isn’t using that feature. But that role should get permissions on, say, the Article content type, whose feature may or may not be enabled. Is there currently in Drupal a way to ensure that when my Special Feature is enabled, if Article is also there, config actions are done? It sounds like the config actions can be set up, and if article is available, they’ll work, and if not, they’ll silently fail. But how about if the article feature is then enabled later? Is there a safe way to tell relevant config actions to try again at that time?

Asked about at Why are user roles in config/install but the associated permissions moved to config/actions ?

Conclusions

There seems to be some conflict between the design and goals of config_actions, which are used by their author to easily ‘fork’ features, and the goal of producing an ecosystem of contributed features that can work together.

But as of right now, it seems building on config_actions is the best way to achieve these other goals also.