Skip to content
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

Cannot run Nest.js app after compiling #666

Closed
techvlad opened this issue Feb 14, 2020 · 9 comments · Fixed by #939
Closed

Cannot run Nest.js app after compiling #666

techvlad opened this issue Feb 14, 2020 · 9 comments · Fixed by #939
Assignees
Labels
Milestone

Comments

@techvlad
Copy link

Describe the bug
swc successful compile Nest.js, but cannot run after compiling

➜ npx swc src -s -d ./dist && node dist/main.js
Successfully compiled 5 files with swc.
[Nest] 23731   - 02/14/2020, 5:27:26 PM   [NestFactory] Starting Nest application...
[Nest] 23731   - 02/14/2020, 5:27:26 PM   [ExceptionHandler] Nest cannot create the module instance. Often, this is because of a circular dependency between modules. Use forwardRef() to avoid it.

(Read more: https://docs.nestjs.com/fundamentals/circular-dependency)
Scope []
 +5ms
Error: Nest cannot create the module instance. Often, this is because of a circular dependency between modules. Use forwardRef() to avoid it.

(Read more: https://docs.nestjs.com/fundamentals/circular-dependency)
Scope []

    at NestContainer.addModule (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/injector/container.js:42:19)
    at DependenciesScanner.insertModule (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/scanner.js:50:31)
    at DependenciesScanner.scanForModules (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/scanner.js:27:43)
    at DependenciesScanner.scan (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/scanner.js:21:20)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
    at async /home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/nest-factory.js:80:17
    at async Function.asyncRun (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/errors/exceptions-zone.js:17:13)
    at async NestFactoryStatic.initialize (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/nest-factory.js:79:13)
    at async NestFactoryStatic.create (/home/hex/Sandbox/nestjs-swc-build/node_modules/@nestjs/core/nest-factory.js:30:9)
    at async bootstrap (/home/hex/Sandbox/nestjs-swc-build/dist/main.js:5:17)`

.swcrc

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": false
    },
    "target": "es2018"
  },
  "module": {
    "type": "commonjs"
  }
}

Example repo

@techvlad
Copy link
Author

Nest.js project was created via default nest-cli

@kdy1 kdy1 self-assigned this Feb 15, 2020
@kdy1 kdy1 added this to the v1.1.24 milestone Feb 15, 2020
kdy1 added a commit to kdy1/swc that referenced this issue Feb 15, 2020
kdy1 added a commit to kdy1/swc that referenced this issue Feb 15, 2020
@kdy1
Copy link
Member

kdy1 commented Feb 15, 2020

@techvlad I did some investigation. It seems like the behavior of the swc almost matches it of babel.

swc generates

var _dec = _common.Module({
  imports: [],
  controllers: [_appController.AppController],
  providers: [_appService.AppService],
});
let AppModule =
  _dec(
    (_class = (function() {
      class AppModule {}
      return AppModule;
    })()),
  ) || _class;

while babel generates

var AppModule =
  ((_dec = (0, _common.Module)({
    imports: [],
    controllers: [_app.AppController],
    providers: [_app2.AppService],
  })),
  _dec(
    (_class = function AppModule() {
      _classCallCheck(this, AppModule);
    }),
  ) || _class);

When I changed the output of swc to

let AppModule =
  _dec(
    (_class = (function() {
      class AppModule {}
      return AppModule;
    })()),
  ) || _class;

, it's behavior become exactly same as babel's one. But the same error occurs anyway.

Thus, I'm not sure if this is issue of the swc. Is this really a bug of swc?

@kdy1
Copy link
Member

kdy1 commented Feb 15, 2020

Note: tsc generates

var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};

AppModule = __decorate([
    Module({
        imports: [],
        controllers: [AppController],
        providers: [AppService],
    })
], AppModule);

which reduces to a call to Reflect.decorate(). I'm not sure if this is correct behavior for legacy decorators.

@kdy1 kdy1 removed this from the v1.1.24 milestone Feb 15, 2020
@kdy1 kdy1 removed their assignment Feb 15, 2020
@kdy1 kdy1 added the E-medium label Mar 30, 2020
@unlight
Copy link

unlight commented Jul 25, 2020

NestJS requires emitDecoratorMetadata: true setting.
This metadata is used by NestJS's dependency injection system.

I think swc should mimic behavior babel-plugin-decorator-metadata or babel-plugin-transform-typescript-metadata

Is there are any plans to implement this?

Update: babel-plugin-decorator-metadata looks like it is for new decorators (not legacy, which typescript uses).

@kdy1
Copy link
Member

kdy1 commented Jul 25, 2020

@unlight Of course. Some decorator fixes are wip.

@kdy1
Copy link
Member

kdy1 commented Aug 6, 2020

I've implemented this, but I want some execution test suite. How did you configured nest-cli to use swc?

@techvlad
Copy link
Author

techvlad commented Aug 6, 2020

nest-cli does not have any compiler options.
Just compile via swc: npx swc src -s -d ./dist && node dist/main.js

@kdy1
Copy link
Member

kdy1 commented Aug 6, 2020

@techvlad Thanks!

@kdy1 kdy1 closed this as completed in #939 Aug 6, 2020
kdy1 added a commit that referenced this issue Aug 6, 2020
swc_ecma_transforms:
 - Allow emitting decorator metadata (#666, #919)

swc:
 - change order of passes to allow decorator using type informations
@swc-bot
Copy link
Collaborator

swc-bot commented Oct 27, 2022

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.

@swc-project swc-project locked as resolved and limited conversation to collaborators Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

Successfully merging a pull request may close this issue.

4 participants