Does this really belong in the Yaml constraint ?

I doubt that this is a common enough use case that justifies to add this feature to the Symfony core.

IMO, now that there is a Yaml constraint, I think config validation will be common.

It allow to validate your Yaml tree directly (e.g. in form submit, or API call) without more action but to create your Configuration class.

That way, you ensure the Yaml can be validate soon in your process without to much code to do it.

IMO, it can be good to also add this to Json constraint too.

I have never see an application where the config for a bundle is managed by a user of the application. Can you explain with more details how your actual use case looks like please?

The case I see is not about bundle's configuration (and you are right, bundle's config must not be managed by your app interface).

It is about configuration in general. In some app, you can find/manage config for other app or parts of the app itself, like Home Assistant for example (just the principle).

In the case of Home Assistant, Yaml is used to configure and customize users' dashboard, directly from the web interface, by each user. And the problem for this example is the lack of validation on submit. With this PR, problem solve.

I know some app I worked on where this capability will have been good.

@WedgeSama I would suggest you to create a custom constraint in your project for that case (or in a third-party bundle if you want to reuse it). I don't think this use case is common enough to justify adding it in the core.

Btw, your proposal requires that the provided config class can be instantiated with no argument, which is not guaranteed at all by the interface.

After a chat with @Neirda24 it may be more relevant to use encapsulation of Collection constraint to do only validation. It will match more the logic of the Validator.

It will do something similar to what I wanted to do, but without symfony/config (it will also solve the config class instance you mention).

I'll update the PR.

If I want to validate a JSON against an actual schema, I would create a new constraint using, for example, https://packagist.org/packages/justinrainbow/json-schema. I'm not sure I would like to rewrite it with constraints by hand.

As far as I can tell, for the Yaml part, the PR only validates that the Yaml is valid, no schema is actually checked? Also, you're restoring an error handler in the validator but you didn't set one, what's the reason?

I recall having a similar need in the past, also related to config management via UI – so +1 for the idea from me.

Instead of putting serializer logic into validator component, how about adding a #[Assert\Serialized(format: '...', constraints: [...])] constraint to symfony/serializer?

And then in the framework config wire @serializer to the SerializedValidator. This way we'd support all the formats that serializer supports. And of course some defaults would need to be configured in case you use the components without the framework.

Perhaps it would be better if this was an optional schema definition within the JSON constraint?
Similar to how the egulias/email-validator is used for email validation, in this case we could use justinrainbow/json-schema.