Manage target modules' dependencies

info.yml files are (mostly) just data. So loading them, updating dependencies, and writing them back to disk seems pretty straight-forward.

However, AFAIK, there's no way to preserve comments in a YAML file when re-writing it. Since these files ought to be under version control, we should be able to recover/preserve these. We should probably add a header comment of our own, to flag that the module is managed by CED, and thus additional comments may be lost, etc.

It seems legit to also extend target modules with custom functionality (or turn existing modules into a CE target modules). As such, there may be additional dependencies apart from those that are detected by the config system.

One approach would be to only ever add dependencies. This seems like it would lead to cruft for the usual use-case (where a target module is just a container for config).

Another approach might be to add a new config_dependencies key to the info.yml files. I don't know that this'd be viable, and the info.yml parser might choke on alien keys. Presumably, this'd also mean that CE needs to take responsibility for enabling those modules.

I think a reasonable compromise, for an initial implementation, would be to allow dependency management to be enabled per target module. This feature could then simply be disabled for modules where we want to manage dependencies manually.

Since this will be opt-in, we should be able to add it in a minor release.

Another approach might be to add a new config_dependencies key to the info.yml files. I don't know that this'd be viable, and the info.yml parser might choke on alien keys. Presumably, this'd also mean that CE needs to take responsibility for enabling those modules.

Last I checked, Config Devel basically does this with their own key you can add to your info.yml files and I know for a fact that you can add arbitrary keys to theme info.yml files because I've done this for my base theme to add additional metadata core doesn't provide out of the box, such as the theme logo image width, height, and alt text, and you can read that via a core service or parser if I recall. I'll have to look into it more, but this might be the way to go.

This might be more challenging that I'd originally thought. On a current client project, we've been seeing lots of configs that that populate module dependencies. However, now that I'm looking for a minimalist test case, it looks like many core configs do not.

Since the first element of a config name is its module, we can try using that to determine a dependency. I'm not sure how reliable this will be.

There will be numerous exceptions here. For example, core fields, such as "timestamp" don't generate their own config, and don't add a module dependency. Perhaps this could be considered a bug

Anyway, this indicates that we're going to have to allow for manual dependencies to be added.

@spiderman suggested that we could probably poll modules' schemas and map module dependencies from there. That seems like a better idea than anything I'd suggested above.