Still insist this is looked into, `createAsyncOptionsProvider` implmentation error

[coderatchet]

If it is intentional that the useExisting async option should resolve to a factory instance, This does not align with the (current documentation)[https://docs.nestjs.com/fundamentals/custom-providers#alias-providers-useexisting]. I believe this would lead to unnecessary complexity that should be solved using Injected tokens in a useFactory provider instead.

It aligns with every custom useExisting implementation (for configuring dynamic modules) we had in the ecosystem before the configurable module class was introduced.

This is the expected behavior. useExisting represents an existing configuration factory provider, not the configuration itself.

Originally posted by @kamilmysliwiec in #15013

I still think the use of useExisting assumes an InjectionToken, not a Factory, according to its use in packages/core/injector/module.ts

This is also supported by the (useExisting)[https://docs.nestjs.com/fundamentals/custom-providers#alias-providers-useexisting] documentation, which describes a provider of an instance (in this case a class function), not a "factory" for the instance.

I have searched for a while for documentation to support your claim, and I don't want to start an argument, especially as your name is against much of this code, however I still believe my assessment has credence, in the least for the sake of clearer documentation describing this behaviour.

[coderatchet]

The ExistingProvider type also suggests this:

/**
 * Interface defining an *Existing* (aliased) type provider.
 *
 * For example:
 * ```typescript
 * const loggerAliasProvider = {
 *   provide: 'AliasedLoggerService',
 *   useExisting: LoggerService
 * };
 * ```
 *
 * @see [Alias providers](https://docs.nestjs.com/fundamentals/custom-providers#alias-providers-useexisting)
 *
 * @publicApi
 */
export interface ExistingProvider<T = any> {
  /**
   * Injection token
   */
  provide: InjectionToken;
  /**
   * Provider to be aliased by the Injection token.
   */
  useExisting: any;
}

the use of the word 'alias', generally does not insinuate a factory, but a referenced object.

[kamilmysliwiec]

You're confusing two different things that just happen to share the same name.

useExisting in the context of registering providers lets you declare an alias - as explained in the docs and as shown in the code snippets you shared

useExisting in the context of dynamic modules' async configuration allows you to pass a token that represents an existing configuration factory provider (as I've already said in the previous issue)

These 2 are different

[coderatchet]

In any case, if the intent of the use class or useExisting in the configurable class builder is to be a factory and not an object provider, then the documentation isn't clear on this.

[kamilmysliwiec]

I just realized that there's indeed no mention of useExisting here https://docs.nestjs.com/fundamentals/dynamic-modules#custom-options-factory-class - adding an example & explanation in this section should make things clearer

[coderatchet]

That would be a good resolution if the behaviour here is intentional, I think the naming here is misleading to an observer familiar with how useExisting works for regular module providers

[coderatchet]

I still think the useExisting property of the dynamic module async options should expand its type to accept injectiontokens if this is the case, as just using a class function explicitly seems unnecessarily restrictive

[kamilmysliwiec]

nestjs/docs.nestjs.com@a7ce2d7