Cannot access before initialization error in NestJs

[michaeldesigaud]

Describe the bug

I'm using swc in a NestJs project and i'm facing the following issue when i run my unit test with jest:

ReferenceError: Cannot access 'DocumentEntity' before initialization

      10 |
      11 | @Entity('documents')
    > 12 | export class DocumentEntity extends EntityObj {
         |              ^
      13 |   @PrimaryGeneratedColumn()
      14 |   id: string;
      15 |

      at Object.DocumentEntity (features/documents/document.entity.ts:12:14)
      at Object.<anonymous> (features/documents/data/document-data.entity.ts:16:14)
      at Object.<anonymous> (features/documents/document.entity.ts:12:29)
      at Object.<anonymous> (features/resources/resource.entity.ts:13:25)
      at Object.<anonymous> (features/resources/resources-db.store.ts:10:25)
      at Object.<anonymous> (features/resources/resources-db.store.spec.ts:5:27)

I think the error is caused by the automapper library which i use in the document-data.entity.ts:

Input code

@Entity('documents-data')
export class DocumentDataEntity {
  @PrimaryColumn()
  @AutoMap()
  key: string;

  @PrimaryColumn({ nullable: false })
  documentId?: string;

  @AutoMap(() => DocumentEntity) // Think error comes from here
  document?: DocumentEntity;
}

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": true
    },
    "target": "es2021",
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true
    }
  },
  "module": {
    "type": "commonjs",
    "noInterop": false
  }
}

FYI, it works with the swc config "target": "es5" but then i've got code coverage issues

Playground link

No response

Expected behavior

I'm expecting the test to run correctly

Actual behavior

No response

Version

1.13.19

Additional context

No response

[weyert]

I am having the same issue without using Nestjs but I do have a decorator on the constructor of my class. I will try to make a reproducible case. For me it also improves things when switching back to targetting es5

[michael-dm]

For anyone having the problem with NestJS, using ModuleRef on one end of the circular definition solves it. See here : https://docs.nestjs.com/fundamentals/module-ref

[dustin-rcg]

I am getting the same error after upgrading swc. I am using ts-node with swc, via my tsconfig.json

  "ts-node": {
    "swc": true
  },

This error is happening pretty much everywhere there is a typescript reference to a class type. For example, in my entity class, the fields will reference typescript types of other entity classes.

It seems to be a problem with the loader not understanding that these are merely type references and not instances of the class object. I can remove the error by the following, but I have to do it all throughout my code base!

Create a trivial typescript type

type Type<T> = T;

Then change all my class type references from Foo to Type<Foo>. For example, if I have a field such as

todos: Todo[];

then it becomes

todos: Type<Todo>[];

When I do this, the circular dependency is resolved. It seems to force the class reference to be treated as just a type, rather than an actual class object instance. Very strange,

[dustin-rcg]

Maybe this is just https://github.com/swc-project/swc/issues/5047 . I sure would like to know what magic makes Type<T> work, and why swc can't do that without the wrapper type.

[timofei-iatsenko]

@dustin-rcg do you have decorators on that classes? With decorators and "decoratorMetadata": true SWC have to inline a type info into the transformed file, and what is from your perspective looks like "type only usage" from SWC perspective would be referencing to type constructor. BTW typescript doing the same, but indeed there are differences. I think differences in how SWC vs TS generating exports / import, order may be?

I also have the same issues in GraphQL models and looking how to resolve it.

[timofei-iatsenko]

I've created a related issue in NestJS Graphql Repo https://github.com/nestjs/graphql/issues/2568

[allanvobraun]

same

[lucas-silveira]

Same

[antonphilin]

Same

[fknop]

Maybe this is just #5047 . I sure would like to know what magic makes Type<T> work, and why swc can't do that without the wrapper type.

This is definitely due to this, I think SWC should understand that the import is used as a type and not a value. I don't know if that's possible. We also encountered this issue and adding Type<T> everywhere is not a great option for us.

[Xiot]

I just ran into this as well, while attempting to migrate a NestJS app from ts-jest to @swc/jest

The issue is a heart caused by a circular dependency, but its also how swc handles it, as ts-jest worked.

This is the relevant parts from the output of ts-jest

// require statements are here
let TeamTasksService = TeamTasksService_1 = class TeamTasksService { ... }
// rest of code
exports.default = TeamTasksService;

The same file transformed with swc produces

Object.defineProperty(exports, "default", {
    enumerable: true,
    get: ()=>TeamTasksService
});
// require statements are here
let foo = require('./foo') // which references this file

// rest of code

The error is surfaced because this file is part of a circular dependency so the default export is getting referenced before this file has had a chance to finish parsing.

[magic-akari]

Maybe this is just #5047 . I sure would like to know what magic makes Type<T> work, and why swc can't do that without the wrapper type.

This is definitely due to this, I think SWC should understand that the import is used as a type and not a value. I don't know if that's possible. We also encountered this issue and adding Type<T> everywhere is not a great option for us.

Is it really being imported as type ?

If so, import type { Foo } from "foo" might be a good solution. ref: https://www.typescriptlang.org/docs/handbook/modules.html#importing-types

importsNotUsedAsValues: "error" will make it easier for you to spot this issue. ref: https://www.typescriptlang.org/tsconfig/#importsNotUsedAsValues

With an eslint rule this can be fixed automatically. ref: https://typescript-eslint.io/rules/consistent-type-imports/

Note:

The emitDecoratorMetadata compiler option changes the code the TypeScript emits. In short - it causes TypeScript to create references to value imports when they are used in a type-only location.

ref: https://typescript-eslint.io/rules/consistent-type-imports/#usage-with-emitdecoratormetadata

If the above is true, I don't think this is an easy fix.

[micalevisk]

@magic-akari I did that but still got the same error due to how the generated js file looks like. I'm not using with jest but swc+node directly. My project has some circular imports (typeorm stuff).

[swc-bot]

This issue has been automatically closed because it received no activity for a month and had no reproduction to investigate. If you think this was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.