## Problem/Motivation A recipe's `composer.json` and its `recipe.yml` `install:` list are both **generated** from the model's computed module dependencies. Neither can be hand-edited durably: `mergeComposer()` overwrites `require` wholesale from the generated set, and `mergeRecipe()` does the same for `install`. ```php foreach (['name', 'type', 'license', 'require'] as $key) { if (array_key_exists($key, $generated)) { $result[$key] = $generated[$key]; } // … } ``` That is correct for anything derivable from the model. It is a gap for a module the model genuinely needs but that Drupal's dependency calculation cannot see. Demonstrated against `drupal-eca-recipe/eca_lib_0033` on a real site: adding `"drupal/eca_tv_demo": "*"` to the recipe's `composer.json` by hand and re-running `drush eca:doc:models` gives ``` added by hand: ['drupal/eca', 'drupal/eca_tv_demo', 'drupal/http_client_manager', 'drupal/modeler_api'] after re-export: ['drupal/eca', 'drupal/http_client_manager', 'drupal/modeler_api'] ``` The entry is gone. ## Why the dependency is invisible `eca_lib_0033` uses the plugin `http_client_manager_command:eca_tv_demo_services:Get Data`. That derivative is **provided** by `http_client_manager`, which is what the model's dependencies name. The derivative only *exists* because `eca_tv_demo` ships an `.http_services_api.yml` file that `HttpServiceApiHandler` discovers from module directories: ```php // http_client_manager/src/HttpServiceApiHandler.php:82 $this->yamlDiscovery = new YamlDiscovery('http_services_api', $this->moduleHandler->getModuleDirectories()); ``` Supplying a YAML file that another module's deriver reads is not a dependency Drupal can compute. The same shape appears wherever a module contributes discoverable YAML rather than code — service definitions, plugin YAML, and similar. Without the module, the recipe applies cleanly and the model is inert: the plugin is unresolved and nothing ever fires. That is the same silent failure mode as a missing content type. ## Proposed resolution A fifth recipe-metadata setting alongside `summary`, `recipes`, `config_actions` and `export_config` from #3588517: ```yaml third_party_settings: modeler_api: modules: - eca_tv_demo ``` Feeding **both** generated outputs, because they serve different halves of the problem: - `composer.json` `require` — gets the code onto the site. - `recipe.yml` `install:` — enables it, which `composer require` alone does not do. Merged with the computed dependencies rather than replacing them, and de-duplicated. Storage is a `sequence` of `string`, so it has none of the dotted-key trouble #3588518 had — a module machine name never contains a dot. The alternative is to leave it to prose in the model's `documentation`, which is what `eca_lib_0033` does today. That works only for a reader who follows instructions, and it cannot be checked. ## Remaining tasks - [ ] Add `modules` to the schema, `ModelOwnerInterface` / `ModelOwnerBase` and the modeler getters, with the same `NULL`-versus-empty semantics as #3588517 - [ ] Merge it into `getComposer()`'s `require` and `getRecipe()`'s `install` - [ ] Kernel coverage that a declared module survives a real `save()` and reaches both files - [ ] Unit coverage that a declared module is merged with, not substituted for, the computed dependencies ## Related - #3588517 — the four settings this extends - #3588518 — the storage-shape defect in one of them