Laravel data v4 support + extra features

[ederuiter]

Besides the laravel-data v4 support this branch contains a bunch of new features that we needed to generate accurate openapi definitions for our projects

• support deeper nested datastructures
• better support for enums (backed enum values are now exported to the openapi schema)
• support for required property of objects (this exports the list of required fields (for objects) in the "required" field)
• support for collections/arrays of simple types (int/string etc)
• you can now configure which middlewares trigger the bearer token security scheme
• workaround for nested arrays (eg: int[][] now generates correct openapi files)
• workaround for GET routes that have a request object (instead of generating a requestBody this now generates query parameters)
• support union types and custom status codes for responses

If needed I can split up this MR for the different features

[ederuiter]

These were the only tests that failed (they didn't trigger an exception anymore) .. as I was not really sure what the intented behaviour should be I skipped these for now; but these should either be removed or something needs fixing

[kukukk]

Hi,

To make v4 support more complete could you, please, add support for Resource classes?
https://spatie.be/docs/laravel-data/v4/as-a-resource/from-data-to-resource#content-resource-classes

[ederuiter]

I currently don't have time to test with Resource classes and we currently don't use them ourselves. But I can give you a few pointers to implement this yourself.

I think most of the building blocks are in place to support this. Currently there are a couple of hardcoded class checks in src/Data/Schema.php (see fromData and the fromDataCollection methods); I think these fail for the Resource classes as they don't inherit from the LaravelData\Data class; but re-use the traits instead.
If you look at how the laravel-data package does this:

protected static function resolveDataTypeKind(string $name, array $acceptedTypes): DataTypeKind
    {
        return match (true) {
            in_array(BaseData::class, $acceptedTypes) => DataTypeKind::DataObject,

The $acceptedTypes is populated in the same file in the resolveAcceptedTypes method:

protected static function resolveAcceptedTypes(string $name): array
    {
        if (! class_exists($name) && ! interface_exists($name)) {
            return [];
        }

        return array_unique([
            ...array_values(class_parents($name)),
            ...array_values(class_implements($name)),
        ]);
    }

So instead of checking with is_a you need to figure out how to re-use (preferrably) or re-implement the laravel-data logic so you accept all DataObject alike objects.

[kukukk]

Hi,

Sorry for the late answer, but I was busy with other things. Now I had some time to look into it.

Based on your explanation I dug deeper and came up with these modifications:

In Schema -> fromData and Schema -> fromDataCollection replace the is_as check with:

        ['kind' => $kind] = AcceptedTypesStorage::getAcceptedTypesAndKind($type_name);
        if ($kind->isNonDataRelated()) {
            throw new RuntimeException("Type {$type_name} is not a Data class");
        }

In Property -> fromDataClass replace the is_as check with:

        ['kind' => $kind] = AcceptedTypesStorage::getAcceptedTypesAndKind($class);
        if ($kind->isNonDataRelated()) {
            throw new RuntimeException('Class does not extend LaravelData');
        }

It would be great if you could do an another modificatio to support single action controllers. It seems that there is a (I would say bug) in Laravel's Route implementation. It offers a public getActionMethod() method, but internally they use a protected getControllerMethod() when running the route action. The logic it uses is: Str::parseCallback($route->action['uses'])[1]. To fix this a small change is needed in Operation.php:
Replace:

            $controller_function = $controller_class->getMethod($route->getActionMethod());

with

            $controller_function = $controller_class->getMethod(Str::parseCallback($route->action['uses'])[1]);

[kukukk]

Can you make these changes in your branch or should I fork it, make these changes and create a PR to your repo?