Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated spec does not match type passed to @Body #1327

Open
2 tasks done
rosslavery opened this issue Oct 21, 2022 · 1 comment
Open
2 tasks done

Generated spec does not match type passed to @Body #1327

rosslavery opened this issue Oct 21, 2022 · 1 comment

Comments

@rosslavery
Copy link

rosslavery commented Oct 21, 2022

Sorting

  • I'm submitting a ...

    • bug report
  • I confirm that I

    • used the search to make sure that a similar issue hasn't already been submit

Expected Behavior

Consider a utility type and example model as follows:

// Reusable utility type
type RepositoryFilterOptions<T> = {
  [P in keyof T]?: T[P] extends string | number ? T[P] | T[P][] : T[P];
};

// Example model
interface ListUser {
  id: string;
  age: number;
  active: boolean;
}

The TS compiler in editor properly understands the computed type as:

type ExampleListUser = RepositoryFilterOptions<ListUser>;

// Resulting type computation:
{
  id?: string | string[];
  age?: number | number[];
  active?: boolean;
}

image

Current Behavior

Currently, tsoa is understanding this type as if the T[P] extends string | number ? T[P] | T[P][] : T[P]; part of the utility type isn't there. It just infers the original type and uses that instead.

type ExampleListUser = RepositoryFilterOptions<ListUser>;

// Simulation of tsoa type computation:
{
  id: string;
  age: number;
  active: boolean;
}

Example spec output (incorrect based on above):

image

Version of the library: 4.1.3
Version of NodeJS: 16 LTS

  • Confirm you were using yarn not npm: [x]
@blipk
Copy link

blipk commented Sep 6, 2024

This is the final thing really stopping tsoa from being really great - type and generics resolution.
If your typing is any more then a level or two deep then you will only get the top level of the typing

It really prevents composability for generating request and response types from models and DTOs which kind of defeats the purpose of much of what tsoa offers.

@lukeautry

@blipk blipk mentioned this issue Sep 6, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants