question: passing Container to TypeORM useContainer fails

[kikoanis]

Description

registering Container with typeorm's useContainer does not work anymore as of the latest release 0.9.0
It throws the following error which is fine for services

Minimal code-snippet showcasing the problem

import { Container } from 'typedi';
import {  useContainer } from 'typeorm';

....
useContainer(Container);

Unless I am missing something, this should not fail.

Expected behavior

It used to work fine. This has stopped working as of 0.9.0.

Actual behavior

It should not fail on passing typedi Container to typeorm

[NoNameProvided]

Just to clarify, you are using the typeorm/typeorm-typedi-extensions package or TypeORM and TypeDI only?

[NoNameProvided]

Related issue: typeorm/typeorm#7267

[kikoanis]

Yes I am using typeorm-typedi-extensions to inject other repositories and services as well as typeorm and typedi

[zifahm]

I got the same error, I removed typeorm-typedi-extensions thinking it wont be compatible with the new version and still got the same error from above.

[NoNameProvided]

Can you try with newly released [email protected]?

If you use only the decorators provided by the extension, I believe you should be good to go. However this release may not solve your problem, if you import extra stuff from TypeORM via Container.get. Then you need to wait for the fix to land in TypeORM.

[marines]

@NoNameProvided I'm having the same issue and new typeorm-typedi-extensions didn't fix it.

        "routing-controllers": "^0.9.0-alpha.6",
        "typedi": "^0.10.0",
        "typeorm": "^0.2.30",
        "typeorm-typedi-extensions": "^0.4.0",
        "typescript": "^4.1.3",

Still getting the
ServiceNotFoundError: Service with "MaybeConstructable<ExpressSessionMiddleware>" identifier was not found in the container. Register it before usage via explicitly calling the "Container.set" function or using the "@Service()" decorator.
error.

The only usages of typedi in my project is only useContainer from routing-controllers and typeorm. Doesn't matter whether I execute either or both.

Update:
Allright, got it working after looking at typestack/routing-controllers#642. I've added @Service() decorator to routing-controller's middleware classes and typeorm's migrations classes.

[yayvery]

@marines Can you provide a snippet of the code that got it working?

[mycodeself]

I'm facing the same issue after upgrade my dependencies

"typedi": "^0.10.0",
"typeorm": "^0.2.30",
"typeorm-typedi-extensions": "^0.4.0",

Downgrading typedi to 0.7.3 make it work again

[marines]

@danbeneventano I mean it's just @Service().

[NoNameProvided]

Can you provide a snippet of the code that got it working?

You need to add the @Service decorator from TypeDI to every class you ever request from the container via Container.get().

[kikoanis]

I can confirm decorating all classes that fail with @Service() fix then issue. Even though it seems unnecessary, it's good enough for now.

[JipSterk]

@danbeneventano here is a sample repository with steps to set it up and run it. it should fail because it cant inject the proper service.

[norenma]

I can confirm decorating all classes that fail with @Service() fix then issue. Even though it seems unnecessary, it's good enough for now.

I have the same problem. What classes are you referring to? For me, as with your example, it is typeORMs ConnectionManager that fails. Did you manage to make that into a @service or are you referring to some other class?

[ianldgs]

For now I have downgraded to [email protected] and it's working.

[NoNameProvided]

@kikoanis Can I ask what services you had to decorate with @Service decorator to make your version work? I want to create a new release of typeorm-typedi-extensions where these types are auto-registered. However looking at the TypeORM repo, it seems they don't use the container much, only to inject the connection manager, which already registered in TypeDI with the current version of [email protected].

[NoNameProvided]

Also, I have released [email protected] which allows setting a different container for TypeDI (check readme), however, I don't think this should solve all the errors.

For that, all services which throw an error should be pre-registered. Can we get a list of those falling services? This way there is no need for modification in TypeORM.

[norenma]

Also, I have released [email protected] which allows setting a different container for TypeDI (check readme), however, I don't think this should solve all the errors.

For that, all services which throw an error should be pre-registered. Can we get a list of those falling services? This way there is no need for modification in TypeORM.

That sounds great! I have only gotten this error on the class ConnectionManager.

[EirikFA]

I am experiencing the same issue with class-validator. Although this seems a bit weird, considering I am not using any services in any custom validators yet (I only added useContainer).

[NoNameProvided]

@EirikFA please open an issue for that in class-validator repo. The problem there is that class-validator will use the provided container internally to resolve some dependencies even if you haven't added anything. A update is needed for it what registers every internally requested class when the container is recorded.

[EirikFA]

Will do! :)
Also noting that I have issues with injecting a PrismaClient, although it might be unrelated to this. Even using Container.set does not work (EDIT: unsurprisingly, the Prisma issue was an error on my part).

[JClackett]

Question: external packages that generate classes will need to now add @service() to all of the internal services? what if the package can't do this, then its not really scalable? for example typegraphql-prisma, generates a load of resolvers, but none of them are now in the container.

[ianldgs]

Question: external packages that generate classes will need to now add @service() to all of the internal services? what if the package can't do this, then its not really scalable? for example typegraphql-prisma, generates a load of resolvers, but none of them are now in the container.

I imagine you could extend the generated class and annotate it? (Doesn't seem ideal, but might be a temporary solution)

[ocboogie]

Since OP screenshotted the error, I'm going to copy and paste the message, so Google can index it:

ServiceNotFoundError: Service with "MaybeConstructable<ConnectionManager>" identifier was not found in the container. Register it before usage via explicitly calling the "Container.set" function or using the "@Service()" decorator.

[sa-webb]

Just incase this helps someone. At the time of writing, I was experiencing the same issue while using the latest versions of the following dependencies. I was able to leave TypeOrm at its latest and simply downgraded typedi and typeorm-typedi-extensions to the versions listed below. Maybe this will help someone.

In my index.js (entry point) file.

...
useContainer(Container);
...

"typedi": "^0.8.0", // downgraded
"typeorm": "^0.2.37", // curent latest
"typeorm-typedi-extensions": "^0.2.3", // downgraded

Working

[4matic]

In [email protected] has been added custom Container to register with TypeORM. So changing from:

import { Container } from "typedi";
import { useContainer } from "typeorm";
useContainer(Container);

to

import { Container } from "typeorm-typedi-extensions";
import { useContainer } from "typeorm";
useContainer(Container);

helps.

[NoNameProvided]

Closing this as solved now. As @4matic mentioned the latest typeorm-typedi-extensions solves the issue reported initially.

The concern raised by @JClackett is worth discussing, if anyone is affected please open a new issue discussing that specific topic.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.