Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(core): ModuleRef#get and #resolve opts default values #10822

Merged

Conversation

micalevisk
Copy link
Member

@micalevisk micalevisk commented Jan 7, 2023

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

when suppling an empty object as options to ModuleRef#get and ModuleRef#resolve methods, defaults options are not taking in count

@Module({
  providers: [{ provide: 'foo', useValue: 123 }]
})
class Foo {}

@Module({
  imports: [Foo]
})
export class AppModule {
  constructor(private readonly moduleRef: ModuleRef) {}

  onModuleInit() {
    this.moduleRef.get('foo', {}) // ends up being { strict: undefined, each: undefined }
    // returns [123]
    // which is wrong since "strict" should be enabled by default and the provider is out of this module
  }
}

What is the new behavior?

this.moduleRef.get('foo', {}) // will raise an 'not found provider' error since "strict" is enabled

I also fixed the type def for the second args of ModuleRef#get/ModuleRef#resolve since it shouldn't be GetOrResolveOptions because that interface is saying that the default value of strict is false, which is wrong for ModuleRef while it's correct for NestApplicationContext.

export interface GetOrResolveOptions {
/**
* If enabled, lookup will only be performed in the host module.
* @default false
*/
strict?: boolean;

Does this PR introduce a breaking change?

  • Yes
  • No

it's a breaking changes for those there are using ModuleRef#get/ModuleRef#resolve wrongly.

@coveralls
Copy link

coveralls commented Jan 7, 2023

Pull Request Test Coverage Report for Build 6573ab44-4df1-4aa7-a2e4-b043db0f71ce

  • 4 of 6 (66.67%) changed or added relevant lines in 1 file are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage decreased (-0.03%) to 93.377%

Changes Missing Coverage Covered Lines Changed/Added Lines %
packages/core/injector/module.ts 4 6 66.67%
Files with Coverage Reduction New Missed Lines %
packages/core/injector/module.ts 1 81.85%
Totals Coverage Status
Change from base Build 9dc8ad2e-5837-4b71-ac65-32c322f0dbd1: -0.03%
Covered Lines: 6204
Relevant Lines: 6644

💛 - Coveralls

@kamilmysliwiec
Copy link
Member

lgtm

@micalevisk micalevisk deleted the fix-type-defs-for-moduleref branch February 1, 2023 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants