fix(core): false-positive value provider not registered error when the value is undefined

[micalevisk]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

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?

import { Module } from '@nestjs/common';

@Module({
  providers: [
    { provide: 'foo', useValue: undefined  },
    { provide: 'bar', useFactory: () => undefined  },
  ],
  exports: [
    // This triggers the 'cannot export a provider ...' error
    'foo',
    // This won't
    'bar',
  ]
})
export class AppModule {}

when exporting some custom value provider that was registered with the value undefined we got the following error

What is the new behavior?

We could now have mandatory custom provider values with the value undefined. Although this unlikely make sense, it's aligned with the present behavior of factory providers that could return undefined

I find this bug when trying to help one dev on our Discord. He was importing some value from a 3rd-party package and that value was used at the useValue. Later he find out that the import clause was wrong (named import vs namespace import), so that has nothing to do with the error raised by nestjs internals. Thus, that error was a false-positive signal on provider not registered within the module.

Does this PR introduce a breaking change?

• Yes
• No

This has implications on circular file imports because in the current version they are caught at bootstrapping time, while after this PR they won't lead to any injection error (given that case). So you should consider this trade-off.

Another solution would be improving that error message to give a hint that the value of the provider might be undefined and suggesting the use of optional: true flag.

[coveralls]

Pull Request Test Coverage Report for Build 0775c6b8-444f-4776-815d-b5a9141e8b88

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 92.885%

---

Totals
Change from base Build 5e72b472-ecc8-4d1e-a9fd-634e8558b976:	0.0%
Covered Lines:	6488
Relevant Lines:	6985

---

💛 - Coveralls