Skip to content

Code-first approach future compatibility with ESM modules #2568

Description

@timofei-iatsenko

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions