Nest: Does the order of module imports matter?

Created on 26 Jan 2018 · 9Comments · Source: nestjs/nest

I'm submitting a...


[ ] Regression 
[ ] Bug report
[ ] Feature request
[X] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

When using Nest with TypeORM integration the TypeOrmModule has to be the first import before my other modules or exceptions are not printed. Documentation does not suggest that order matters.

Both OtherModule and AnotherModule import TypeOrmModule.forFeature(...). This may have something to do with it.

Configuration that doesn't work:

@Module({
    imports: [
        OtherModule,
        AnotherModule,
        TypeOrmModule.forRoot({
            type: 'postgres',
            host: process.env.DB_HOST,
            port: parseInt(process.env.DB_PORT),
            username: process.env.DB_USER,
            password: process.env.DB_PASS,
            database: process.env.DB_NAME,
            entities: [__dirname + '/**/*.entity{.ts,.js}'],
            synchronize: true
        })
    ]
})
export class ApplicationModule {}

Output:

[Nest] 17643   - 1/25/2018, 3:44:35 PM   [NestFactory] Starting Nest application...
[Nest] 17643   - 1/25/2018, 3:44:35 PM   [InstanceLoader] ApplicationModule dependencies initialized +12ms

// Exit code is 0

Expected behavior

With a small change the error is printed out:

@Module({
    imports: [
        TypeOrmModule.forRoot({
            type: 'postgres',
            host: process.env.DB_HOST,
            port: parseInt(process.env.DB_PORT),
            username: process.env.DB_USER,
            password: process.env.DB_PASS,
            database: process.env.DB_NAME,
            entities: [__dirname + '/**/*.entity{.ts,.js}'],
            synchronize: true
        }),
        OtherModule,
        AnotherModule
    ]
})
export class ApplicationModule {}

Output:

[Nest] 18088   - 1/25/2018, 3:49:32 PM   [NestFactory] Starting Nest application...
[Nest] 18088   - 1/25/2018, 3:49:32 PM   [InstanceLoader] ApplicationModule dependencies initialized +11ms
[Nest] 18088   - 1/25/2018, 3:49:32 PM   [InstanceLoader] TypeOrmModule dependencies initialized +2ms
[Nest] 18088   - 1/25/2018, 3:49:32 PM   [ExceptionHandler] connect ECONNREFUSED 127.0.0.1:5432
Error: connect ECONNREFUSED 127.0.0.1:5432
    at Object.exports._errnoException (util.js:1020:11)
    at exports._exceptionWithHostPort (util.js:1043:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
 1: node::Abort() [node]
 2: 0x10a04d9 [node]
 3: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [node]
 4: 0x9ee7fe [node]
 5: 0x9ef09e [node]
 6: 0x7c9d0e092a7
[1]    18088 abort      node dist/main.js

Environment


Nest version: 4.5.9
`@nestjs/typeorm`: 2.0.0
`typeorm`: 0.1.11


For Tooling issues:
- Node version: 6.12.0
- Platform:  Linux (Ubuntu 17.10)

Others:

Upgrading to the latest LTS version of Node does not change the outcome.

type type todo 💚

Source

cmcahoon

👍1

All 9 comments

I imagine it does matter. They are instantiated in the order they appear, and since the TypeORM provider doesn't exist when the other modules are instantiated, it can not find the provider.

wbhob on 3 Feb 2018

I imagine it does matter. They are instantiated in the order they appear, and since the TypeORM provider doesn't exist when the other modules are instantiated, it can not find the provider.

wbhob on 3 Feb 2018

Yes it matters, And sorry for not providing something like this in docs.
should be marked as #TODO in docs

shekohex on 3 Feb 2018

👍1

Thanks for the confirmation. I figured as much once I reordered the imports.

cmcahoon on 3 Feb 2018

👍1

This can be closed @kamilmysliwiec

wbhob on 3 Feb 2018

Hi @cmcahoon,
Actually, the order of modules doesn't matter. It's a bug that Nest sometime consumes internal exceptions. Thanks for reporting, will fix it :)