ES6 import vs @Configuration({imports: []})

[borjapazr]

Hi 👋

When you want to import and register a provider (a service, for example) you can do it in the following way, as explained in the documentation and as you commented in this issue.

// MyService.ts

import { Injectable } from "@tsed/di";

@Injectable()
export class MyService {
  constructor() {}
}

// Server.ts

import { MyService } from "./MyService"; // if the symbole is used
import "./MyService"; // if the symbole isn't used but you have use it because you use hooks

But reviewing the documentation I saw that using the @Configuration decorator there is the imports property, which serves, literally, for the following:

Add providers or modules here. These modules or provider will be built before the server itself.

// MyService.ts

import { Injectable } from "@tsed/di";

@Injectable()
export class MyService {
  constructor() {}
}

// Server.ts

import { Configuration } from "@tsed/di";
import { MyService } from "./MyService";

@Configuration({
  imports: [MyService]
})
export class Server {}

So, looking at both alternatives it seems that they serve the same purpose, right? The question is: What should imports be used for? Is it analogous to the ES6 import?

Thanks in advance 🙏

Regards!

[Romakita]

Hello @borjapazr

imports was introduced later to cover a specific usage.

In most case, ES6 import is enough. In your given example adding MyService to imports field special effect because your class is already decorated by @Injectable.

But in this example imports is required:

// Server.ts

import { Configuration } from "@tsed/di";
class MyService {
}

@Configuration({
  imports: [MyService]  // add MyService to the registry because MyService isn't decorated.
})
export class Server {}

But isn't the initial reason of the imports presences. imports field is here for the following reason:

• to force MyService to be instanciate before the class decorated by @Module or @Configuration
• to declare provider conditionally (depending on env variable) or declare alias

Example:

  imports: [
    {
      token: TimeslotsRepository, // baseClass
      useClass: DynamoDBTimeslotsRepository // DynamoDB version of timeslotRepository in Serverless context
    }
  ]

So, imports it's here to fine tuning the injected service by the DI where the decorator doesn't solve.

See you

[borjapazr]

Hi, @Romakita.

Great! Perfect!

Just one last thing. I'm not quite clear on the following, maybe I didn't understand it correctly:

In your given example adding MyService to imports field special effect because your class is already decorated by @Injectable.

Do you mean that in these cases, if MyService (for example) is already decorated with @Injectable, it wouldn't be necessary to add it to the imports field (inside @Configuration), right? Simply using the ES6 import would be enough, correct? If it wasn't decorated, then it would be necessary to add it to the imports field (@Configuration) to register that service, as you explained.

Thanks again!

[Romakita]

Sorry missed to add negation. So yes adding MyService to imports field when the class is already decorated has no effect ^^