No olvides exportar los providers en NestJS
Tags: nestjs, typescript, di
Published: 2019-11-04 19:40:57

---
title: No olvides exportar los providers en NestJS
published: true
description: 
tags: nestjs, typescript, di
---

Si ya conoces NestJS, sabrás que tiene mucha similitud con el framework de front-end Angular. Y no es pura casualidad, dado que NestJS basa gran parte de su arquitectura en librerías del propio Angular.

![](https://miro.medium.com/max/2124/1*bYHZw5xC3g4o3-2S9rMC9A.png)

Si estás comenzando con NestJS, **es muy importante que centres energías en aprender cómo funciona el mecanismo de contenedores de Inversión de Control**. A su vez, has de saber que se parece bastante al mecanismo de Angular **pero no son exactamente iguales**.

![](https://www.tutorialsteacher.com/Content/images/ioc/principles-and-patterns.png)

Por ejemplo, en Angular encontramos un artefacto llamado Component (decorador @component) mientras que en Nest tenemos un artefacto llamado Controller (decorador @controller) que vendría a ser un parecido. Esto se debe a que **Nest no tiene que lidiar con temas de view rendering** y se centra directamente en el concepto de controlador.

Vamos a hacer un repaso a la interfaz que tienen los decoradores @NgModule y @Module en cada framework —Angular y Nest respectivamente.


<figure>
```ts
// Angular front-end AdminModule
@NgModule({
  declarations: [MyComponent, MyDirective, MyPipe],
  entryComponents: [],
  providers: [MyService], // imported and auto-public for everyone
  imports: [AdminDashboardModule],
  exports: [MyComponent, MyDirective, MyPipe]
})
export default class AdminModule {};

// Nest back-end AdminModule
@Module({
  providers: [MyService, MyRepository, MyFactory, MyHelper],
  controllers: [AdminController],
  imports: [CoreModule],
  exports: [AdminService, MyService/*re-export needed to be public for the enquirer*/]
})
export default class AdminModule {}
```
  <figcaption>Comparando interfaces de los módulos en Angular y Nest</figcaption>
</figure>

Vamos a hablar en concreto de la propiedad _exports_ en ambos frameworks.

# Propiedad exports

En Nest, la propiedad _export_ en un @Module define qué _Providers_ serán expuestos hacia el módulo que lo está importando, también llamado _enquirer_.

```ts
  ...
  providers: [MyService, MyRepository, MyFactory, MyHelper],
  exports: [MyService, MyRepository] // Es necesario exportar para hacerlo público
  ...
```

> Recordemos. Un _Provider_ es aquel elemento que puede ser inyectado como dependencia. Ejemplos de _Providers_ son: servicios, repositorios, factories, helpers, etc.

Mientras que en Angular, la propiedad _export_ en un @NgModule permite listar qué declaraciones—componentes, directivas y pipes— serán expuestas. Todo _Provider_ en la propiedad providers será público y accesible en toda la aplicación bootstrapeada.

```ts
  ...
  providers: [MyService], // Serán públicos automáticamente
  ...
```

Exceptuando aquel módulo que sea Lazy Loaded dado que tendrá su propio lazy loaded injector.

> Lo importante de esto es que sepas que en Nest has de especificar qué _Providers_ quieres que sean públicos, ya que **por defecto no se exportará ninguno**. Esto es una gran diferencia con Angular por que en dicho framework, los _Providers_ **son registrados en el módulo root/root injector de toda la aplicación**—accesible por lo tanto por todos los módulos—.

El objetivo en Nest es encapsular y aislar 📦 por completo todos los Providers del Module. Pero, si quieres que alguno sea público para quien importe dicho módulo, entonces deberás especificarlo en la propiedad _exports_.

```ts
cats.module.ts 🐈

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService] // hago CatsService público!
})
export class CatsModule {}
```

Espero que este recordatorio y explicación te sean de utilidad en tu proyecto de Nest 🧐.