-
Notifications
You must be signed in to change notification settings - Fork 396
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
Code-first approach future compatibility with ESM modules #2568
Comments
It seems that the solution is quite simple. The export type Relation<T> = T This comment in SWC issue also suggests the same solution. I'm not very familiar with this library, but maybe I can try to implement this. |
I'm not sure how related this is to NestJS. I was able to work around this by doing author: AuthorModel & {}; To prevent the compiler from saving a runtime reference to that class for that property type. |
@dotoleeoak Thank you, adding
|
You can try implicit decorator with CLI Plugin in Graphql case. Because root problem is
4.Generate
In case you want to add option look like |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
This idea of this discussion appeared after trying to adopt SWC for the testing purposes. In fact SWC stated as drop-in replacement for ts-node, and as long you don't use any of cli plugins you should be good to go.
Thanks to the fact SWC the only one from many "not-official typescript transpilers" who supports
emitDecoratorMetadata
.However, naive adoption by replacing
ts-node
with SWC showed errors "Cannot access before iniitialization" root cause of which is explained here swc-project/swc#5047In short The code is falling on circular references in GraphQLmodels:
Prior
@swc/core@1.2.206"
it would work, but after is not.Here is what the author said about it:
In other words, SWC transpiles as much as closer to ESM standard and this snippet of code would not work in native ESM modules either.
So there no action points from SWC sides, and it should be responsibility of framework authors to be nake it compatible with newer standards.
Describe the solution you'd like
Other backend projects such as TypeORM , also suffer from similar problem, but they have a clear solution for that which is described in the docs.
https://typeorm.io/#relations-in-esm-projects
So the point of this issue is to provide Official, Documented Solution, on how to solve circular refences problems in ESM projects. Something similar to
Relation
type in TypeORM.How the Relation type might work under the hood?
I didn't read the original
Relation
sourcecode, but believe it might be implemented like that:It's effectively just voids metadata inlining in place where it used:
Without
Relation
type:Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
Sooner or later ecosystem should migrate to native ESM modules. NestJs is not an exclusion.
The text was updated successfully, but these errors were encountered: