Container.merge in v6?

[y-nk]

it seems the method is gone, so how would one merge 2 or more containers?

[notaphplover]

Hey @y-nk, the method is gone in inversify@7. You should delegate in ContainerModules instead.

1. Given c1 and c2 two containers.
2. Given m1 and m2 two container modules with the bindings for c1 and c2 respectively.
3. Merging c1 and c2 is equivalent to create a container and load m1 and m2.

[notaphplover]

Hey @y-nk,

I've tried to prototype this in my head and i wondered, wouldn't that be more convenient to use a container to register the container modules? if each registered as singleton, then the registry would be part of the DI resolution phase. of course, that container would probably be a singleton itself (as a static member of the NestJsLikeContainerModule class?

As long as it's centralized it should be ok. But this approach is tricky, it's easy to make mistakes. I see you added internal and external containers in your NestJsLikeContainerModule in the stackblitz code. Module2 cannot access Module1 internal container, so when it tries to provide a Service2 service it cannot resolve a Service1 service since the binding is in the internal container of Module1.

EDIT: i've updated my stackblitz further. i'm not sure but it seems there's a bug? the registry is declared as new Container({ defaultScope: 'Singleton' }) so i would expect that every single binding is resolved as a singleton, but when adding a console.log in the generated class it gets called for every getAsync() call. I've added logs to highlight it. What happens at first makes total sense to me, but the part highlighted is weird.

It's an issue in your end. You are initializing modules again:

const module1 = await new Module1().resolve();

You're initializing the module again. Consider the following alternative:

const module1 = NestJsLikeContainerModule.registry.get(Module1).resolve();

[y-nk]

As long as it's centralized it should be ok. But this approach is tricky, it's easy to make mistakes. I see you added internal and external containers in your NestJsLikeContainerModule in the stackblitz code. Module2 cannot access Module1 internal container, so when it tries to provide a Service2 service it cannot resolve a Service1 service since the binding is in the internal container of Module1.

i've made that the externalContainer is a bridge/proxy to the internalContainer with:

    if (this.options.exports) {
      for (const moduleId of this.options.exports) {
        console.log('creating a passthrough to', moduleId);

        this.externalContainer
          .bind<any>(moduleId)
          .toDynamicValue(() => this.internalContainer.get(moduleId));
      }
    }

it was my fault on that part. a night of clarity brought that i should have changed .toFactory to .toDynamicValue to make it working (since i was wrongly influenced by nest's useFactory behavior)

---

It's an issue in your end. You are initializing modules again:

You're right, thanks for pointing that out. I've wapped the new ().resolve() to the .registry.get and indeed, it worked.

---

I've moved around the things again, and going back to it after a few hours gave the necessary step back needed to see my errors. If you are curious the stackblitz has been updated and it does work now :)

I'm mostly puzzled in your opinion on this implementation since you mentioned:

But this approach is tricky, it's easy to make mistakes.

What would be tricky/easy to make mistakes here?

[notaphplover]

What would be tricky/easy to make mistakes here?

It's sort of easy to miss that 2 modules are the same if and only if they are the same object. That was my only concern

[y-nk]

@notaphplover i understand. thanks a lot for this conversation, it's been a while since i've had met someone teaching such complicated concepts so well. the codebase is crazy clean too, i've tried to read some parts and it's a gem. 🙏🙏🙏

[notaphplover]

You are very welcome. Thank you so much for your kind words, it means a lot 😊