Thank you very much for working on this feature.
I gave it a try and it works really well.

• The per-environment configuration need to be added. This is the same as the current root definition (that need to be a type), with key following this pattern:when@[a-zA-Z0-9]+
• The JSON schema file will be different for each environment, because the bundles are not the sames. The JSON schema must allow any additional root keys forwhen@ other environments.

Here is the files that are not validated by the generated JSON schema.

doctrine.yaml

• Somedoctrine configuration are not recognized.

framework.yaml

• All configuration thatcanBeEnabled (likeframework.esi) must accept a boolean value. AllequivalentValues must be allowed.

routing.yaml

• "Missing required property 'resource'. Since the configurations are merged from multiple files (and defaults) properties cannot be required in a single Yaml file.

validator.yaml

• Theframework.validation.auto_mapping.<class-name> value must be an object, but anempty array is accepted.

Thanks for quick review/comment@GromNaN!

Resolvedwhen@(though it does not account for env-specific extensions yet), removed"required": [...] from the schema, added usingequivalentValues.

The validator issue still on to-do list, not sure on what basis to allow the empty array –maybeuseAttributeAsKey just addedmaxItems: 0 to non-prototyped arrays.

The doctrine issue seems to be caused bynormalization in a closure, some possible solutions below 👇

1. always allow extra keys / have"additionalProperties": true in the schema (for every subschema), not to cause false-positives on keys that for whatever reason don't appear in the schema
2. do some manual override / manually defined schema to cover this special case.
3. convert(dynamically?)the xml schema to json schema(not sure if it matches yaml one-to-one)

Resolvedwhen@(though it does not account for env-specific extensions yet), removed"required": [...] from the schema, added usingequivalentValues.

Thanks, perfect.

The validator issue still on to-do list, not sure on what basis to allow the empty array – maybeuseAttributeAsKey 🤔

I think the JSON schema can be a bit more strict than the config validation rules. But this error may be hiding something else.

The doctrine issue seems to be caused bynormalization in a closure, some possible solutions below 👇

1. always allow extra keys / have"additionalProperties": true in the schema (for every subschema), not to cause false-positives on keys that for whatever reason don't appear in the schema

Arbitrary additional properties are not allowed by the Config component. This would fail the purpose of the JSON schema.

2. do some manual override / manually defined schema to cover this special case.

It's the last option if you really can't do any better.

3. convert(dynamically?)the xml schema to json schema(not sure if it matches yaml one-to-one)

I'd prefer to be able to generate the xsd rather than use it.

Maybe we don't need to support this for a first version, since there's an alternative syntax (more verbose).

Did a whole lot of cleanup based on the comments.

I also managed to workaround the Doctrine issue by allowing any type when$node->getNormalizedTypes() containsExprBuilder::TYPE_ANY.

This of course means we don't get a schema for those, but I think it's better than false-positives when using example configuration.

Also added a deprecation message to the schema which shows up quite nicely now

Awesome, the deprecation message is exactly why I want such schema validation.

I'm a little stuck with the support for env-specific extensions: since the schema is generated inside the kernel, it does not seem possible to generate schemas for other environments. And since the kernel class is not really exposed anywhere, it's not trivial to create multiple instances of the kernel with different envs (not that it would be a great idea anyway).

Best I could think of is

1. always only build schema for the current environment
2. in addition to saving the schema into single file inside env-specific directory, also insert a reference into common file outside env-specific dir

This could look something like

var/cache/dev/config.schema.jsonvar/cache/test/config.schema.jsonvar/cache/whatever/config.schema.jsonvar/config.schema.json # references all files above, like {"when@dev": { "$ref": "cache/dev/config.schema.json" } }

The downside with this solution is that unless you build the container for those other envs, you also don't get the schema for those. Also, I doubt that many people build the container locally for any env butdev &test.

If someone has a better approach, great!

I tried this with PHPStorm, but the file loading doesn't work yet.

Yeah, that is sad. I ended up putting everything in a single file,%kernel.build_dir%/../config.schema.json.

Also switched fromarray to\stdClass because after merging configs between envs I was getting[] where{} was expected, breaking the whole schema.

So now you'd need to run

bin/console --env=devbin/console --env=testbin/console --env=prod

etc to populate all the configs – though in reality I think most projects have all the bundles & extensions available indev, thus nothing extra exceptdev build should be needed.