Expose more of the internal API

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.

[kamilmysliwiec]

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

[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