Using openapi-typescript-codegen, why does this Swagger schema produce a model of Record<string, any>?

My swagger.json includes this schema:

"schemas": {
            "BuildFruitBody": {
                "properties": {
                    "id": {
                        "type": "number",
                        "format": "double"
                    },
                    "name": {
                        "type": "string"
                    }
                },
                "type": "object",
                "additionalProperties": true
            }
        },

However, when I generate the axios client via npx openapi-typescript-codegen -i ./swagger.json -o src/services/api -c axios, the resulting model is as below:

/* generated using openapi-typescript-codegen -- do no edit */
/* istanbul ignore file */
/* tslint:disable */
/* eslint-disable */

export type BuildFruitBody = Record<string, any>;

Am I doing something wrong here? Why doesn’t the model reflect the schema?

Full swagger.json below:

{
    "components": {
        "examples": {},
        "headers": {},
        "parameters": {},
        "requestBodies": {},
        "responses": {},
        "schemas": {
            "BuildFruitBody": {
                "properties": {
                    "id": {
                        "type": "number",
                        "format": "double"
                    },
                    "name": {
                        "type": "string"
                    }
                },
                "type": "object",
                "additionalProperties": true
            }
        },
        "securitySchemes": {}
    },
    "info": {
        "title": "backend",
        "contact": {}
    },
    "openapi": "3.0.0",
    "paths": {
        "/swagger.json": {
            "get": {
                "operationId": "Get",
                "responses": {
                    "200": {
                        "description": "Ok",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "string"
                                }
                            }
                        }
                    }
                },
                "tags": [
                    "swagger"
                ],
                "security": [],
                "parameters": []
            }
        },
        "/fruit": {
            "post": {
                "operationId": "Get",
                "responses": {
                    "200": {
                        "description": "Ok",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "string"
                                }
                            }
                        }
                    }
                },
                "tags": [
                    "fruit"
                ],
                "security": [],
                "parameters": [],
                "requestBody": {
                    "required": true,
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/BuildFruitBody"
                            }
                        }
                    }
                }
            }
        }
    },
    "servers": [
        {
            "url": "/"
        }
    ]
}

>Solution :

Am I doing something wrong here?

Not within the code as far as I can see.

Why doesn’t the model reflect the schema?

Actually, it does reflect the schema. But perhaps it’s the mental model that is differently reflecting the schema model or not yet well understood?

When given the following in a JSON Schema (cf. additionalProperties JSON Schema Core DRAFT-2020-12)

            "type": "object",
            "additionalProperties": true

then the Record<Keys, Type> utility type

 Record<string, any>

seems legit as in JSON Text an attribute/property name is a JSON String can be any of the seven: JSON Object, JSON Array, JSON String, JSON Number, "true", "false" and "null" (cf. json.org).

The best suggestion I can give is to put it under automated test and then confront yourself with the problem that the first test did fail unexpectedly (or didn’t fail for the expected reason), then fix it.

Either the schema or the expectation, depends on your requirements.

And as defraggled
confirms per comment below:

Ah yes, setting additionalProperties: false resolves it. Thanks

The requirement was indeed to not have additional properties (which could have been left out for validation).

Which is a strong sign that it could have been left out of the schema alltogether, additionalProperties has been moved from JSON Schema Validation to JSON Schema Core recently (DRAFT-2020-12).