Nullable refs when documenting type manually

[romalytvynenko]

When a type is documented via PHPDoc and future ref is used with null in union, information about null is lost:

/** @var User|null */

[alanstriglio]

I found a similar issue when documenting a nullable type via PHPdoc like this:

/** @var array<string, string> | null */

[romalytvynenko]

@alanstriglio are you using the latest version (0.11.14)?

[alanstriglio]

I'm using 0.11.9

[romalytvynenko]

@alanstriglio try the latest. If problem persists, reopen the issue.

[alanstriglio]

I'm experiencing the same result with the latest version (0.11.14). I can't reopen this issue myself, could you please reopen it?

[darkbasic]

I would like to add my two cents to the issue: whenever you refer to a named object in the PHPDoc it ends up using anyOf in the generated json and information about null is not lost:

/** @var MappingItem|null */

"anyOf": [
    {
        "$ref": "#\/components\/schemas\/MappingItem"
    },
    {
        "type": "null"
    }
]

Instead whenever you use a built-in type it ends up using an array of types and information about null is lost:

/** @var array<string, string> | null */

"type": [
    "object",
    "null"
],
"additionalProperties": {
    "type": "string"
}

When I say "information about null is lost" is mean that openapi-generator-cli with the typescript generator doesn't add null to the union.

This is in sharp contrast with whatever Stoplight shows for the same type when it generates the APIs documentation via the same openapi json:

So there is a chance that the generated openapi JSON is correct and there could be a bug in the typescript openapi-generator. I don't know the OpenAPI 3.1 specs well enough to tell who's at fault.

[romalytvynenko]

@darkbasic thanks for more explanation. Indeed, this is a valid JSON Schema and type generator should've handled it properly. So I'm closing the issue for now.