Promises cache their values by default, so multiple calls to resolve() return the first resolution result. It's like a Java Future that way. https://www.ecma-international.org/ecma-262/6.0/#sec-promise-resolve-functions

sure, but I'd rather not have to do container.resolve<Promise<Foo> when I could (in theory) just do container.resolve<Foo>

Dependency injection is by nature synchronous, so you would need to register the Foo instance after your first resolve in that case.

I have come up with this as sort of a pattern, but I still question whether it might be possible to block on resolve, when registering a promise (yes I know DI is blocking by nature), basically a way of telling the container, this will be available, so wait for it...

  await createContentfulConnector(container.resolve(Beans.CONTENTFUL_CONNECTOR_CONFIG))
    .then((conn) => {
      container.register(Beans.CONTENTFUL_CONNECTOR, { useValue: conn });
    });

As far as I know, there is no way to make asynchronous things block in JavaScript (without using a native C/C++ module). The pattern you posted above is exactly what I was thinking, but you'd still need to make sure your program awaits the resolve/register before trying to resolve the actual instance (which would be the responsibility of the program, not the DI container).

I could see a case for adding a helper for the above pattern into tsyringe though (to guide usage to the pattern)

I'd be ok with that, or maybe just some documentation. Though I can't help but wondering if maybe there's a way that a flag could be set internally for "building in progress" then also have that updated once the promise is resolved, in this way the resolve could be called as normal, but continue to block until ready.

another solution would be to inject proxies and do the blocking (if necessary) in there (is that possible?) though I would suggest some way of saying proxy mode is acceptable.

I think the best way to handle this right now would be to update the documentation for this case. Even if the container internally tracked whether or not "building is in progress", there would still need to be some external await ... since we can't force JS to block. Because of that, I feel the solution should live entirely outside of the container (via the helper function you suggested for example)

so, I wrote this...

export function factory(explicit?: symbol, { singleton = true, container = rootContainer() } = {}) {
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    const token = !!explicit ? explicit : Symbol.for(propertyKey);
    const factory = (c: DependencyContainer) => {
      const obj = descriptor.value.apply(target, [c]);
      if (obj instanceof Promise) {
        const handler = {
          get: (target: Promise<any>, prop: string, receiver: any) => {
            return target.then((o) => {
              return o[prop].apply(o);
            });
          },
        };
        return new Proxy(obj, handler);
      }
      return obj;
    };
    const finalFactory = singleton ? instanceCachingFactory(factory) : factory;
    container.register(token, { useFactory: finalFactory });
  };

would something like proxyForPromiseFactory(...) be a good idea to fulfill this? (this is a first attempt, if you see something broken please let me know)

looked into the proxy thing more... it doesn't work, the more I think about this, I'm not sure it's a good idea, in our case it's me trying to support an existing anti-pattern.

Yeah, I still think the best fix for this is to document how to handle async resolutions

I was reading this issue and thinking if there is a better way of doing this. Can we specify on the arguments of the factory the dependencies to build the new bean and then the framework can orchestrate to call the factory function just when all their dependencies are resolved?

Something like this:

  testContainer.register(
    TestBeans.APOLLO_TEST_CLIENT,
    {
      useFactory: instanceCachingFactory<Promise<ApolloServerTestClient>>(TestBeans.APOLLO_SERVER, (c, server: ApolloServer)
        => createTestClient(server)),
    });