Nest: Expose more of the internal API

[fwoelffel]

Feature Request

Is your feature request related to a problem? Please describe.

This feature request isn't really related to a problem but more like a concern about the support of what looks like some internal API. As I'd like to keep this short, I'll dive directly into the technical details. I'm using the InstanceWrapper and Module interfaces from the injector subdirectory of the core package. Those two elements are not exposed through the package root barrel file, and the imports look like this:

import { InstanceWrapper } from '@nestjs/core/injector/instance-wrapper';
import { Module } from '@nestjs/core/injector/module';

I'm wondering if it is safe to use these imports since those are not exposed at the core's root.

The same goes for:

• @nestjs/common/interfaces
  
  
  
  • Injectable
  
  
  • ModuleMetadata
  
  
  • Type
  
  
  • ClassProvider
  
  
  • ValueProvider
  
  
  • FactoryProvider
  
  
• @nestjs/core/metadata-scanner
  
  
  
  • MetadataScanner
  
  

If you feel like you need more concrete details, have a look at this class.

Certainly, others would like to have some more internals exposed. Maybe this issue would be the right place to build a list of what could/should be exposed.

Describe the solution you'd like

My proposal is to simply expose more of the internal API, as long as the newly expose elements are considered stable.

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

This would allow the community to get a better grasp to NestJS' internals and write better and more robust integrations.

---

_English is obviously not my first language. If, in any case, you feel like you can't completely understand what I ask for, don't hesitate to tell me and I'll do my best to rewrite this issue._

[BrunnerLivio]

I'm wondering if it is safe to use these imports since those are not exposed at the core's root.

No, it is not safe to use this. If we would change these elements it would not be declared as breaking change and we will not give further support in case you application breaks because of it.

---

Nonetheless what you are requesting is definitely mandatory for Nest. I think it would be interesting to compile a list of internals, which we should expose or make similar functionality part of the public API.

What comes to my mind:

• #2412
• #1438
• Good example of internal functionality which should be part of the public API

[marcus-sa]

I think we need to discuss this further.
If we have to utilize Bazel properly we need to have a structure similar to https://github.com/angular/angular/tree/master/packages/common as opposed to our current https://github.com/nestjs/nest/tree/master/packages/common

[Toxicable]

You don't have to use ng_package and therefore have a clear distinction between public and private apis with bazel.
ng_package is primarily focused towards frontend applications where the you give the bundler multiple options on what format to use.
With Nodejs packages ts_library -> npm_package makes a bunch more sense and should maintain the current api that exists in this repository

[marcus-sa]

@Toxicable the use case is the exact same as http in the common package
You don't see Angular export their http module in their common module's public api?
It doesn't make sense for us to do so either, since IDE's will resolve down to the @nestjs/common/http path instead.

https://github.com/nestjs/nest/issues/2772

[kamilmysliwiec]

Most of them (MetadataScanner, Type, ClassProvider, ValueProvider, FactoryProvider etc) are now exported from root

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.