- Issue created by @mxr576
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:
"*"
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.This problem also impacts any contrib dependency that is being installed by a Recipe, making it a widespread issue affecting the entire Recipe ecosystem.
"*"
patternImplement automatic config entity dependency resolution during Recipe application. The system should:
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."
New configuration options may be added to Recipe definitions to control automatic dependency resolution behavior. The exact API will be determined during implementation.
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.
Active
11.0 🔥
recipe system