Union types are ignored by validation

[pluma]

✏️ Describe the bug

Given a Data class with a constructor like this:

__construct(
  public string $id,
  public SomeData|OtherData $thing
) {}

I would expect the validation to first try to validate the parameter $thing using SomeData, then fall back to OtherData and for the first matching type to be used for this property when using ::from($jsonString).

But instead the validator will generate rules for $thing based on the type information of SomeData and only that information because it prioritizes having a fully denormalized list of rules even if it means discarding the alternatives.

There does seem to be actual logic around UnionType in this library but the validator doesn't support it for validation and everything else seems to run downstream from that.

↪️ To Reproduce

it('cannot validate union types', function () {
    class ExampleData extends Data
    {
        public function __construct(
          public string $id,
          public SomeData|OtherData $thing
        ) {
        }
    }

    class SomeData extends Data
    {
        public function __construct(
            #[In('SomeThing')]
            public string|Optional $type,
            public string $taste
        ) {
        }
    }

    class OtherData extends Data
    {
        public function __construct(
            #[In('OtherThing')]
            public string $type,
            public int $size
        ) {
        }
    }

    dd(BaseData::validateAndCreate(['id' => 'abc', 'thing' => ['type' => 'OtherThing', 'size' => 23]]));
});

✅ Expected behavior

I would expect the validator to generate rules matching the union type (i.e. either-or) and validation to succeed with the value being of the matching type (i.e. OtherData in this test case).

🖥️ Versions

Laravel: 11.40.0
Laravel Data: 4.13.0
PHP: 8.3.9

[pluma]

After digging through the discussions, it seems this is a deliberate choice but I'm not seeing an error indicating that the union types are unsupported. This seems like a weird constraint that I'm unsure how to work around given the real-world data format I'm trying to represent.

[rubenvanassche]

Yeah this is expected behaviour, in the past we've thrown an exception when using union types but that would make it impossible to use them even for cases where validation wasn't required. The thing you want where we create rules based upon data type one and if that doesn't work data type to is impossible with Laravel's validator unless we start creating multiple validators for the different case which can run quickly out of hand when you've got nested and collected objects.

A PR was submitted to add this kind of functionality but you'll have to define morph keys in advance when constructing objects: #921 Still need to review it but that will probably be the solution for these kinds of problems.