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#5047
In short The code is falling on circular references in GraphQLmodels:
// author.model.ts
import { ObjectType, Field } from '@nestjs/graphql';
import { BookModel } from './book.model';
@ObjectType()
export class AuthorModel {
@Field(() => BookModel)
book?: BookModel;
}
// book.model.ts
import { ObjectType, Field } from '@nestjs/graphql';
import { AuthorModel } from './author.model';
@ObjectType()
export class BookModel {
@Field(() => AuthorModel)
author: AuthorModel;
}
Prior @swc/core@1.2.206" it would work, but after is not.
Here is what the author said about it:
Your input is wrong. It's wrong because ESM is a standard
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:
export type Relation<T> = T;
It's effectively just voids metadata inlining in place where it used:
type Relation<T> = T;
@ObjectType()
export class MyModel {
public myProperty: Relation<TestClass>;
}
↓ ↓ ↓ ↓ ↓ ↓
// relation is not exists in runtime, so typeof Relation would be undefined
__metadata("design:type", typeof Relation === "undefined" ? Object : Relation)
Without Relation type:
@ObjectType()
export class MyModel {
public myProperty: TestClass;
}
↓ ↓ ↓ ↓ ↓ ↓
// Tries to access TestClass and therefore trigger TestClass initialization
__metadata("design:type", typeof TestClass === "undefined" ? Object : TestClass)
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.
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-nodewith 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
Relationtype in TypeORM.How the Relation type might work under the hood?
I didn't read the original
Relationsourcecode, but believe it might be implemented like that:It's effectively just voids metadata inlining in place where it used:
Without
Relationtype: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.