TypeScript types generated as optional but should be required

[nonameolsson]

First of all, I want to thank you for building a really great tool that wilI make development easier 👍

I am using Kiota to generate TypeScript code. It is really easy to use, but I am getting problems with the generated types.

OpenAPI schema

schemas:
  Station:
    type: object
    required:
      - name
      - id

OpenAPI schema with nullable

  schemas:
    Station:
      type: object
      required:
        - name
        - id
      properties:
        id:
          nullable: false
          type: integer
          format: int64
          example: 17
        name:
          nullable: false
          type: string
          example: Trelleborg

Swagger

Kiota generated types

export interface Station extends AdditionalDataHolder, Parsable {
    /**
     * Stores additional data not described in the OpenAPI description found when deserializing. Can be used for serialization as well.
     */
    additionalData?: Record<string, unknown>;
    /**
     * The id property
     */
    id?: number | undefined;
    /**
     * The name property
     */
    name?: string | undefined;
}

Notice that both id and name are defined as: name?: string | undefined.

Questions

1. Why are they generated as optional when they are, in OpenAPI, defined as required and non-nullable?
2. Why is generated both with ? and undefined

Thank you so much for an awesome tool! I do appreciate all feedback on this, so that I an progress.

Additional references

• When I try openapi-generator-cli to generate, this works as expected.
• Looking at the samples here, https://github.com/microsoft/kiota-samples/tree/main/petstore/typescript/src/models, ll properties on the model types are also undefined/optional.

[baywet]

Hi @nonameolsson
Thanks for your interest in kiota and for reaching out.

1. This is a design decision, lots of APIs allow for field selection via query parameters, or partial representations during updates and since the models can be used both as response and request body, having nullable properties makes them more reusable.
2. You are correct, this is redundant, on properties we could loose the undefined, we need to keep it on setters since they don't support the ? notation.

More generally we should implement some kind of generated signal to avoid triggering linters for generated code, if this is available for eslint/ts parser. In the meantime we could fix that ad-hoc redundancy, would you be willing to submit a pull request for that?

The code that emits the property is located here

kiota/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs

Line 46 in 4eb8187

writer.WriteLine($"{conventions.GetAccessModifier(codeElement.Access)} {codeElement.NamePrefix}{codeElement.Name.ToFirstCharacterLowerCase()}{(codeElement.Type.IsNullable ? "?" : string.Empty)}: {returnType}{(isFlagEnum ? "[]" : string.Empty)}{(codeElement.Type.IsNullable ? " | undefined" : string.Empty)};");

[baywet]

As per the generated annotation, this can be done through comments

/* eslint-disable */
/* generated by ... */

...

/* eslint-enable */

This would need to be implemented here (and in enum and in interface and in function)

kiota/src/Kiota.Builder/Writers/TypeScript/CodeClassDeclarationWriter.cs

Line 20 in ef8f508

_codeUsingWriter.WriteCodeElement(codeElement.Usings, parentNamespace, writer);

As well as the closing equivalent

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[baywet]

Assigning to myself and moving to 1.7 since @nonameolsson doesn't seem to want to submit a pull request.

[baywet]

Authored #3318 to address the concerns above.

[bkoelman]

@nonameolsson There's a follow-up issue at #3911, please upvote if you're still interested.

[naeimsf]

Hi @nonameolsson Thanks for your interest in kiota and for reaching out.

1. This is a design decision, lots of APIs allow for field selection via query parameters, or partial representations during updates and since the models can be used both as response and request body, having nullable properties makes them more reusable.
2. You are correct, this is redundant, on properties we could loose the undefined, we need to keep it on setters since they don't support the ? notation.

More generally we should implement some kind of generated signal to avoid triggering linters for generated code, if this is available for eslint/ts parser. In the meantime we could fix that ad-hoc redundancy, would you be willing to submit a pull request for that?

The code that emits the property is located here

kiota/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs

Line 46 in 4eb8187

writer.WriteLine($"{conventions.GetAccessModifier(codeElement.Access)} {codeElement.NamePrefix}{codeElement.Name.ToFirstCharacterLowerCase()}{(codeElement.Type.IsNullable ? "?" : string.Empty)}: {returnType}{(isFlagEnum ? "[]" : string.Empty)}{(codeElement.Type.IsNullable ? " | undefined" : string.Empty)};");

Hi @baywet, thanks for the reply. Anyway to keep some fields required ? (.e.g. Id in this case )

[baywet]

Not today no

[naeimsf]

anything in the roadmap?

[baywet]

yes #3911