leonardfactory / babel-plugin-transform-typescript-metadata

Babel plugin to emit decorator metadata like typescript compiler
MIT License
215 stars 17 forks source link

Issue with generated code on circular dependency #42

Open kelvien opened 3 years ago

kelvien commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

kelvien commented 3 years ago

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 commented 3 years ago

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

MatthieuCoelho commented 3 years ago

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

leonardfactory commented 3 years ago

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