Support object literal and object inference

[SkyaTura]

Summary

• SDK Version: 3.0.8
• Actual behavior: object literals and object inference won't import anything
• Expected behavior:
  • somehow define the correct type
  • use any as return type
  • or, at least, throw an error or a warn explaining the limitation

Example 1: type defined on controller

input

@Controller('/hello')
export class HelloController {
  constructor(private readonly helloService: HelloService) {}

  @Get()
  hello(): { message: string } {
    return { message: 'Hello World' };
  }
}

output

import type { __type } from "./../../../modules/hello/hello.controller";

export namespace hello
{
    export type Output = Primitive<__type>;
}

Example 2: type from service

input

@Injectable()
export class HelloService {
  world(): { message: string } {
    return { message: 'Hello World' };
  }
}

@Controller('/hello')
export class HelloController {
  constructor(private readonly helloService: HelloService) {}

  @Get()
  hello() {
    return this.helloService.world();
  }
}

output

import type { __type } from "./../../../modules/hello/hello.service";

export namespace hello
{
    export type Output = Primitive<__type>;
}

Example 3: type inference

input

@Injectable()
export class HelloService {
  world() {
    return { message: 'Hello World' };
  }
}

@Controller('/hello')
export class HelloController {
  constructor(private readonly helloService: HelloService) {}

  @Get()
  hello() {
    return this.helloService.world();
  }
}

output

import type { __object } from "./../../../modules/hello/hello.service";

export namespace hello
{
    export type Output = Primitive<__object>;
}

[SkyaTura]

@samchon depending on your thoughts about how this should be solved, I would be happy to help with this one too.

My only limitation is that I don't know deeply about reflection yet. ~I actually just learnt what it is, with your code~ 🙈

[samchon]

Then, I will solve this problem by myself. Thanks for reporting.

[SkyaTura]

@samchon is it possible to bring whole type declarations to the output source, instead of just import?

In projects that use nest as private modular packages, it would also be useful to create a whole new independent package for the SDK.

[samchon]

@SkyaTura

Writing whole DTO without import statement is enough possible llike below:

• swagger.json generated by nestia
• typescript-json

However, need to distinguish which to import or re-write the whole DTO.

Have you any plan to dstinguish them? What about distinguish them by object-literal-expression?

//----
// IMPORT
//----
// WHEN DTO TYPE IS CLEARLY DEFINED
export interface IFormalDto {
    id: string;
    name: string;
}

//----
// WHOLE RE-WRITE
//----
// OBJECT-LITERAL-EXPRESSION
class SomeController {
    someMethod(): Promise<{ id: string; name: string; }>
}

// ALIAS TYPE FOR OBJECT-LITERAL-EXPRESSION
type SomeAlias = {
    id: string;
    name: string;
};

[SkyaTura]

@samchon

Would be nice to have a configuration flag that allows you to switch between "always rewrite", which could be used to create a fully independant package, or "import when possible", which would work like you said.

If I didn't misunderstood, the implementation os the second option is harder because the type isn't always clear, right?

---

Thinking further about it, would be useful as well if, in the future, we could, optionally, pass each type to a transformer, or some kind of hooks, defined in nestia.config, that could be used to create helper functions like form validation and object generators.

May I create an issue to elaborate how could this be useful and how could be the usage, or do you think it's out of the project scope?

[SkyaTura]

@samchon how about using Custom AST Transformers?

@ksaldana1 had a pretty similar scenario as we do, and as demonstrated here, and in an awesome blog post, which describes the development of the idea in steps.

I think this could also be useful in #141, if approved.

[samchon]

@SkyaTura I'd been busy by another open source project. I'll try this on this sunday.

However, when nestia re-writes all DTO, have you any idea to where those new DTOs to be placed in?

Also, do you have any idea if duplicated DTO name exists?

[SkyaTura]

Hmm... I think, ideally a SDK should have unique type definitions, and by extension, I would always try to avoid duplicates in the API as well.

But this is definitely not a well adopted as standard and should be supported by a generator.

Maybe using namespaces to replicate the original path tree, but I really need to wonder a lit bit about this question.

If we had infinite resources I would suggest multiple strategies, but unfortunitely we should also think what would be more feasable.

[samchon]

@SkyaTura Then which directory name would be better when generating DTO automatically?

Also, how to do if duplicated directory exists?