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.

Instead of one big file, we could generate one file per bundle.
That would solve the problem ofwhen@ and that would align with the practice of splitting config files per bundle.

Instead of one big file, we could generate one file per bundle. That would solve the problem ofwhen@ and that would align with the practice of splitting config files per bundle.

That's a very good idea, and it would solve our issue.

It would only solve the issue if we iterated the bundles in some other way than getting the bundles from theKernel#getBundles(), because it's not guaranteed that any environment has all the bundles available. And I don't think it's possible to do since the user may not havebundles.php at all, instead, have bundles inlined in theApp\Kernel class, and even have custom php logic when to enable a bundle.

Another issue:previously we faced the issue where PHPStorm does not understand referenced schemas – if that's still the case, then a file per bundle is not too great. Of course one can say "it's not a Symfony issue" but no DX is improved if the IDE doesn't use the schema(s).

I have to admit this PR is too much work for me right now, especially since a brick wall was hit due tobeforeNormalization stuff(to solve this, only reasonable option I see would be to include hard-coded json schemas in bundles, similar to#61282). If someone wants to continue from here / start over, feel free.

Closing in favor of#62125