BTW, let me know when you have finished, i could test it

i tend to prefer concrete UUID, ULID, ... validators. It allows for more fine grained control per type. E.g. ensure a specific UUID version maybe.

I'd also think we should either support sf/uid as well as ramsey/uuid, but not an issue for me.

Im not sure about the form type either, nor the console command.

👍 for the serializer part
for the validator part, I agree with@ro0NL, it must be possible to specify the type of UUID that is allowed

I've not reviewed other parts.

Hi@ro0NL@dunglas , that is the case, thetypes option allow you to choose betweenULID,UUID_V1,UUID_V3, etc.

Another possibility would be to have 2 options :

• type: either ULID or UUID
• versions: UUID version (this option would have no effect if type is ULID)

Or another possibility: 2 different constraints, 1 ULID constraint and 1 UUID constraint, with aversions option on the UUID one.

What do you think is better?

Maybe you could split the PR into smaller ones so that people can focus on the components they know best?

Or another possibility: 2 different constraints, [...]
What do you think is better?

i strongly prefer constraints per case.

I've split this PR in 3 smaller PR, one per component:

• Normalizer:[Serializer] add UidNormalizer #36406
• Validator:[Validator] UID Constraint. #36407
• Command:[Uid] add command to generate UIDs #36405

I'm closing this PR.