Module Providers Reflection Bug When Using Index Files for Imports

I’m submitting a…

[ ] Regression 
[X] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Under the following conditions, NestJS will throw an exception with no helpful error message:

1. An index.ts is present in the root folder of NestJS Module A
2. NestJS Module A registers a provider, using a TS import statement that leverages the index.ts file
3. NestJS Module B registers NestJS Module A, using a TS import statement the leverages the index.ts file

(If this is difficult to understand, see Repo steps, which may be easier)

The following error is thrown, which gives no indication at all of where the error originates in a developer’s code:

TypeError: Cannot read property 'provide' of undefined
    at Module.isCustomProvider (\nest\sample\01-cats-app\node_modules\@nestjs\core\injector\module.js:143:48)
    at Module.addComponent (\nest\sample\01-cats-app\node_modules\@nestjs\core\injector\module.js:131:18)
    at NestContainer.addComponent (\nest\sample\01-cats-app\node_modules\@nestjs\core\injector\container.js:79:23)
    at DependenciesScanner.storeComponent (\nest\sample\01-cats-app\node_modules\@nestjs\core\scanner.js:155:35)
    at components.map.component (\nest\sample\01-cats-app\node_modules\@nestjs\core\scanner.js:73:18)
    at Array.map (<anonymous>)
    at DependenciesScanner.reflectComponents (\nest\sample\01-cats-app\node_modules\@nestjs\core\scanner.js:72:20)
    at DependenciesScanner.scanModulesForDependencies (\nest\sample\01-cats-app\node_modules\@nestjs\core\scanner.js:51:18)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:721:11)

This bug is somewhat obscure, and has a workaround. However, it is fiendishly difficult to debug (I just lost 4 hours on it), so I am reporting for the benefit of others.

The work-around is to import Nest JS Modules directly, and not via Index files.

Expected behavior

Either:

• NestJS correctly resolves the import statement via index files OR
• A helpful error message is emitted

Minimal reproduction of the problem with instructions

I have attached a git patch to this issue that will reproduce the bug in the cats example of the nestjs repo (I had to change the extension to .txt to upload, so just change back to .diff to use)

Repro steps are:

1. Add index.ts file to root of a NestJS folder containing a NestJS Module
2. Register a NestJS Provider using an import statement that references the index.ts file
3. Register this NestJS Module in another NestJS Module using an import statement this same index.ts file

What is the motivation / use case for changing the behavior?

Remove a potential DI gotcha, and reduce the barrier to entry for developers picking up NestJS.

Environment

Nest version: 5.3.0

 
For Tooling issues:
- Node version: 10.1.0
- Platform:  Windows

[kamilmysliwiec]

In the next patch release, we’ll show more descriptive error message 😃

[marcus-sa]

I gotcha, I’m currently creating a dynamic API for 3 different game engines where almost all three share identical databases etc, but I’m trying to create common classes and modules that they all can extend and share off, but unfortunately that’s pretty impossible when using the @nestjs/typeorm module, aswell as circular dependencies etc. There’s poor error messages, for example even when you got a common module, you still have to register the providers or modules, you can’t just export them, because they need to be a part of the same module scope where they’re getting exported from.

@Module({
    // imports: [SomeModule], <-- required
	exports: [SomeModule],
})
export class CommonModule {}

This would throw an error, since Nest requires the SomeModule to be imported before it can be exported, even though it wouldn’t be resolved/used in that specific scope, which is a different behavior compared to module resolution in Angular.