Issue with generated code on circular dependency

[kelvien]

Issue It seems like the generated code through this Babel plugin raises an issue in using a variable before it is initialized.

let User = ...
_dec9 = Reflect.metadata("design:type", typeof Profile === "undefined" ? Object : Profile)
...

let Profile = ...
_dec9 = Reflect.metadata("design:type", typeof User === "undefined" ? Object : User)

I did see the same issue reported by someone here - https://stackoverflow.com/questions/61297622/typescript-metadata-reflection-references-other-classes-before-they-are-defined, but I don't think it's closed with a solution to the core problem.

Context I'm using TypeORM for my interaction with a database. And in this example I defined two entities that need each other (a one-to-one relationship) I provide a minimal reproduction code in this repo - https://github.com/kelvien/repro-next-circ-metadata/

It seems like you've mentioned this as one of the pitfalls. I'm just wondering if there is an alternate way in solving this issue, and perhaps a longer term solution to this.

[leonardfactory]

Usually in TypeORM you can simply use @OneToOne(type => Entity) instead of @OneToOne(Entity) to resolve the circular dependency which is unsupported directly in JS. Have you tried this way?

[kelvien]

Do you mean passing the string instead of the function, right? Suggested here - https://github.com/typeorm/typeorm/issues/4190 I tried that too and it didn't work. Here is the generated code:

_dec4 = Object(typeorm["OneToOne"])('User'), _dec5 = Reflect.metadata("design:type", typeof User === "undefined" ? Object : User)

The relationship is referenced by string, but the Reflect.metadata is doing that typeof check with the class that does not exist yet.

[leonardfactory]

Didn't know about the string version, however the problem here is in the type definition (user: User;) not the relationship definition (@OneToOne('User', 'user'))

I may suggest to type user: User; as user: User | undefined;. This should relax the type definition

[kelvien]

I gave that a try, but the generated code doesn't change at all Code:

  @OneToOne('Profile')
  profile?: Profile | undefined;

Transpiled code

_dec9 = Reflect.metadata("design:type", typeof Profile === "undefined" ? Object : Profile

[kelvien]

Changing it to Profile | null also generate the same code. But profile?: Profile | string results into _dec26 = Reflect.metadata("design:type", Object), obviously not what I wanted but at least has less stricter type check

[kelvien]

Update: I also notice that my Babel/Webpack is outputting a different result between dev and prod. And it seems like it works fine if Webpack bundles my barrel file correctly (a rollup index file for all of my db models). I put more details of my question here - https://stackoverflow.com/questions/65102724/inconsistent-webpack-with-babel-output-in-using-a-barrel-file-between-dev-and-pr

[mmahalwy]

@kelvien any luck with this? I see you're using nextjs too

[kelvien]

Hey @mmahalwy, one alternative was to put the models with circular dependency into one file, it's not the most ideal approach, but I can't seem to find a better solution other than fixing the transpiler itself.

[mmahalwy]

@kelvien oh yeah, but that could get really messy really quickly 😓

[MatthieuCoelho]

Got the same issue with nextjs, still no solution ? =(

[leonardfactory]

Probably TypeScript is smarter here while generating decorators and is wrapping them in functions. I'll see if this is solvable using this plugin alone, or if the problem arises from babel decorators generation process