Error thrown on `moduleRef.resolve()` is a breaking change

Bug Report

Current behavior

Calling moduleRef.resolve() on non-transient providers throws an error when it did not before 7.1.2.

The relevant commit is:

https://github.com/nestjs/nest/commit/439736f051384492813bed469682a48f3c8935e0

Input Code

import { Injectable } from '@nestjs/common';
import { ModuleRef } from '@nestjs/core';

import { MyClass } from './MyClass';

@Injectable()
export class Foo {
  constructor(private readonly moduleRef: ModuleRef) {}

  async build(): Promise<MyClass> {
    return await this.moduleRef.resolve(MyClass);
  }
}

Expected behavior

I understand that resolve should only be called for transient-scoped providers, but before this update, it did not throw an error when not doing so. This is a breaking change introduced in a patch version. I have full coverage in my repos, so I was able to catch this, but for anyone who is relying on Nest not to release breaking changes in minor updates, this will be a problem.

Possible Solution

Revert the change. Re-introduce it in a major version update.

[kamilmysliwiec]

Since there’s no easy way to dynamically determine the scope of a provider, I’ve reverted this breaking change for now (+ error message was misleading either way 😅 ). Fixed in the latest release!

[janhartigan]

@maximelkin The reasoning behind this makes sense given how Nest’s injector works behind the scenes. The idea is that resolve is intended to be used to force-resolve a dependency chain that has some non-global-scoped providers in it. In the Nest world, these kinds of providers don’t get instantiated until the a request comes in, so it makes sense that you might need an async method to do the work. get is intended to be used for globally-scoped providers.

I think a case could be made for having a method available that does either/or…it’s not always easy to know when a particular provider is request scoped or not (although frequently this is a red flag for abusing the provider scopes).