Open ltnscp9028 opened 6 months ago
The feature proposal you're describing suggests supporting to export implicit types inferred.
for Example,
@Controller('foo') export class FooController { @Post() foo(@Body() body: {fooRequest: string}) { return {foo: 'bar'} } }
In the code below, I expect the type inference to be as follows:
interface FooControllerFooRequest { fooRequest: string } interface FooControllerFooResponse { foo: string }
The interface content doesn't necessarily need to this pattern (Controller class name + Controller class method + Request/Response).
Only, It can be any value that is easy for users to distinguish.
This enables Nestia users to convert implicit type inference into explicit type inference through Nestia.
Also support migration through nestia.
e.g. npx nestia migrate implict command,
npx nestia migrate implict
AS-IS
TO-BE
@Controller('foo') export class FooController { @Post() foo(@Body() body: FooRequest): FooResponse { return {foo: 'bar'} } }
To achieve this, export type support is necessary. Alternatively, users can create a type in a path specified by them.
If Support this feature, Nestia-driven development becomes feasible.
The new cli command would be npx nestia explicit
npx nestia explicit
The feature proposal you're describing suggests supporting to export implicit types inferred.
for Example,
In the code below, I expect the type inference to be as follows:
The interface content doesn't necessarily need to this pattern (Controller class name + Controller class method + Request/Response).
Only, It can be any value that is easy for users to distinguish.
This enables Nestia users to convert implicit type inference into explicit type inference through Nestia.
Also support migration through nestia.
e.g.
npx nestia migrate implict
command,AS-IS
TO-BE
To achieve this, export type support is necessary. Alternatively, users can create a type in a path specified by them.
If Support this feature, Nestia-driven development becomes feasible.