Type Error. ObjectSerializer expects a date but I want to pass it a string

[BenSaxon]

Describe the bug
Type Error. ObjectSerializer expects a date but gets a string.

TypeError: data.toISOString is not a function
    at ObjectSerializer.serialize (file:///Users/bensaxon/Documents/code/monorepo/src/private/console/node_modules/.pnpm/@[email protected]/node_modules/@kubernetes/client-node/dist/gen/models/ObjectSerializer.js:2024:29)

The issue is happening here.

The code expects data to be a Date object with a toISOString method.

Instead, when I log the result, I actually get a string, already in ISO format, such as:

2025-01-30T09:58:20.000Z

This is because the resource that I pass into the client has a metadata.creationTimestamp field that is a string. I would rather not have to convert it into a Date. Since I receive it as a string from API requests. I like it as a string. I know it's "supposed" to be a Date according to the type, but it's just impractical. I think it's a bad developer experience. Also, this error does not occur in v0.

Client Version
1.0.0

To Reproduce
Steps to reproduce the behaviour:

The error is thrown when trying to make a PUT request.
Ensure that resource.metadata.creationTimestamp is a string, not a date object.

Make a Patch request:

    const response = await client.patch(
      resource as KubernetesObject,
      undefined,
      undefined,
      undefined,
      undefined,
      PatchStrategy.MergePatch
    );

Expected behaviour

I expect the error not to throw. I suggest putting a conditional inside the serialize function that checks if data is of type string before assuming it's a Date object. If data is a string, then return it as is, else return data.toISOstring().

[brendandburns]

The decision about how to handle this is part of the code generator, specifically the files here:

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache

We rely on code generation because the surface area of the Kubernetes API is too large to have hand-written code maintained by a small number of maintainers.

If you want to raise a PR on that repo to modify the generator so that it can handle both strings or Date objects, I bet they will accept it, but that's where the change needs to be made.