Auto-resolve config entity dependencies when applying recipes

Created on 26 June 2025, 13 days ago

Problem/Motivation

We are at the beginning of transforming our platform to use Recipes and replace those "config bomb" modules (our slang) that provide config entities with Recipes.

We have Module A with core.entity_form_display.A.default.yml, which depends on field.field.node.A.layout_builder__layout, which in turn depends on field.storage.node.layout_builder__layout. The latter is provided by Module B, and Module A depends on Module B. When these modules are installed the "regular way," everything works as expected.

However, when I import Module A's config from Recipe X, even if I use the "*" pattern, the Recipe install fails with: "Attempted to create, modify or delete an instance of field with name layout_builder__layout on entity type node when the field storage does not exist." Why? Because as the author of the Recipe, I also become responsible for resolving config entity dependencies and importing all necessary config entities from Module B, since having Module B installed by the Recipe Installer isn't enough.

This creates several issues:

  • Sustainability concerns: Config entity dependency chains across modules could be endless, and future versions of Module A could introduce config entities with dependencies on config entities from Module C, which could break the installation of Recipe X.
  • Incomplete module states: Not using the "*" pattern for config import leads to the same config dependency resolution problem, plus it leaves modules installed in an "incomplete" state. Site builders will see that Module A is installed (by Recipe X) but XYZ config entities (like content entity types, path aliases, etc) are not installed, and there's no easy way to get them installed after the Module A was installed by a Recipe.
  • Changed expected behavior: The "default expected behavior" of a module that both the module author and site builders are used to changes, because only those config entities are imported from the module that the Recipe author decided to include.
  • High barrier to entry: Recipe authors need to have a nearly superhuman understanding of dependency trees, and specifically dependencies as Drupal lays them out internally, creating a real barrier to Recipe adoption.

This problem also impacts any contrib dependency that is being installed by a Recipe, making it a widespread issue affecting the entire Recipe ecosystem.

Steps to reproduce

  1. Create Module A with config entities that depend on config entities from Module B
  2. Create Recipe X that installs Module A and imports its config using the "*" pattern
  3. Ensure Module B is also installed by the Recipe
  4. Attempt to apply Recipe X
  5. Observe the failure due to missing config entity dependencies

Proposed resolution

Implement automatic config entity dependency resolution during Recipe application. The system should:

  • Automatically import dependent config entities: When a Recipe specifies a config entity for import, the system should automatically identify and import all config entities that the specified entity depends on, even if they come from other modules.
  • Handle runtime dependency computation: Find a way to compute and resolve config entity dependency trees for whitelisted config dependencies, even though dependencies are computed at runtime and may change as the runtime environment does.
  • Maintain Recipe author control: Allow Recipe authors to opt into this behavior while maintaining the ability to explicitly control which config entities are imported when needed.
  • Preserve existing functionality: Ensure that existing Recipes continue to work as expected while providing this enhanced dependency resolution capability.

As highlighted by @phenaproxima in the originating Slack discussion, while this presents technical challenges due to runtime dependency computation, solving this once would significantly improve the Recipe developer experience and reduce the manual burden of dependency resolution. @phenaproxima noted that "config dependencies are fundamentally computed at runtime, so as the recipe applies, the dependencies may shift" and that "anyone who wants to write a complex recipe needs to have a nearly superhuman understanding of dependency trees, and specifically dependencies as Drupal lays them out internally. It's a real barrier."

Remaining tasks

  • Research feasibility of computing config entity dependencies ahead of Recipe application
  • Identify technical approaches for automatic dependency resolution during Recipe application
  • Design API for Recipe authors to control automatic dependency resolution behavior
  • Implement dependency resolution mechanism
  • Add comprehensive test coverage for various dependency scenarios
  • Update Recipe documentation to reflect new dependency resolution capabilities
  • Consider performance implications of automatic dependency resolution

API changes

New configuration options may be added to Recipe definitions to control automatic dependency resolution behavior. The exact API will be determined during implementation.

Release notes snippet

Recipes now automatically resolve config entity dependencies during application, reducing the manual burden on Recipe authors to explicitly include all dependent config entities from installed modules. This improvement makes Recipe authoring more sustainable and reduces the likelihood of incomplete module installations.

Feature request
Status

Active

Version

11.0 🔥

Component

recipe system

Created by

🇭🇺Hungary mxr576 Hungary

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024