Allow adding dynamic configuration schema

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

This seems more like a feature request.

Still wondering if it's a valid use case but may help to have a test case to show the issue.

So I think that on its own the use-case is definitely valid and it would things a fair bit easier for certain advanced use-cases to be able to use PHP to produce the config schema. The reason that we explicitly disallow this at the moment (and @Gábor Hojtsy (or anyone else) please do correct me if I'm misremembering) is that for translatability you need to be able to determine the config schema statically. I.e. you need to be able to check out any version of drupal core or a contrib module via git and be able to say which parts of any config are translatable. And - while it's certainly not super trivial - that's currently possible, even with a very complex view you are able to determine exactly which key is translatable and which is not. And you can do that with potx → (which in fact does exactly that, as far as I know) but you can also that with Python or Go if you are so inclined. And as soon we introduce dynamic schema into the mix that is no longer possible. So as far as I can tell this is "won't fix", unfortunately, but I surely may be missing something or not considering other factors.

Totally agree that this makes sense and is still super valid. 🐛 Fix config schema Fixed is one of many good examples :)

I had a use case where the plugins were being dynamically generated from YAML files, and while an incredibly generic config schema could be used for all of them, we wanted to provide the specific config schema for each one based on the YAML plugin definition, instead of having to duplicate both the YAML plugins and the config schema for each individual one. I think there's still a valid use case for this.

We had a similar issue in DS, see 🐛 Config schema issues with extended DS layouts Active to allow layouts having additional configuration. Any tips always welcome, although I don't think there is one :)