Sácale partido a los puntos de entrada secundarios de tu librería Angular.

Alguna vez te has preguntado si una librería tan simple puede afectar al rendimiento, ¿o no puede? O, por qué me obliga mi librería a instalar todas peerDependencies, sabiendo que no voy a utilizar los módulos que son dependientes de librerías de terceros. O, te has preguntado, ¿qué son y por qué necesitamos puntos de entrada secundarios? Entonces, si te has formulado algunas de las anteriores preguntas, este es tu post :)

Dado que una librería se puede utilizar en muchos lugares, el rendimiento es un aspecto crítico. Y, en este punto, ¡entran en juego los puntos de entrada secundarios!

Al aprovechar los puntos de entrada secundarios, buscamos una mejor arquitectura, compatibilidad con treeshaking, tamaños de paquetes más pequeños y, por lo tanto, aplicaciones más rápidas.

Antes de nada, os dejo un glosario de términos.

• Tree-shaking es la eliminación de código muerto. Significa que los módulos no utilizados no se incluirán en el paquete durante el proceso de compilación. Puede reducir significativamente el tamaño del código que tenemos en nuestra aplicación.
• PeerDependecies: cuando una dependencia aparece en un paquete como peerDependency, no se instala automáticamente. En su lugar, el código que incluye el paquete debe incluirlo como su dependencia. La aplicación que vaya a consumir esta librería es la responsable de instalar esta dependencia de manera manual.
• Chunk: cuando Webpack transpila los archivos TypeScript a JavaScript, crea "fragmentos" que pueden representar partes de archivos o archivos completos, según la configuración de compilación.
• Public-api.ts: la API pública de una librería se mantiene en el archivo public-api.ts. Cualquier cosa exportada desde este archivo se hace pública cuando una librería se importa a una aplicación.

Nuestro caso

Y ¿qué mejor que entender esto con un ejemplo?

Empezamos creando nuestra librería de componentes usando el CLI de Angular:

$ ng new my-lib --create-application=false

$ cd my-lib
$ ng generate library my-lib

Nuestra librería va a constar de dos módulos: simple-text y custom-time.

$ ng g c simple-text
$ ng g m simple-text

$ ng g c custom-time
$ ng g m custom-time

simple-text.component.ts va a ser un componente sin dependencias.

import { Component } from '@angular/core';

@Component({
  selector: 'simple-text',
  template: `
    <div>I have no dependencies!</div>`
})

export class SimpleTextComponent {}

custom-time.component.ts va a depender de la librería moment. Ejecutamos el siguiente comando para instalar la librería:

$ npm i moment

import { Component } from '@angular/core';
import * as moment_ from 'moment';
const moment = moment_;

@Component({
  selector: 'custom-time',
  template: `
    <div>Hey, Custom Time:</div>
    <div>{{ time }}</div>
  `
})

export class CustomTimeComponent {
  time: string;

  constructor() {
    this.time = moment().format();
  }
}

Exportamos en el fichero public-api.ts los componentes y módulos creados anteriormente.

/*
 * Public API Surface of my-lib
 */
export * from './simple-text/simple-text.component';
export * from './simple-text/simple-text.module';

export * from './custom-time/custom-time.component';
export * from './custom-time/custom-time.module';

Ya que uno de nuestros componentes depende de moment, debemos especificarla en nuestro my-lib/package.json:

{
 "name": "my-lib",
 "version": "0.0.1",
 "peerDependencies": {
   "@angular/common": "^8.2.14",
   "@angular/core": "^8.2.14",
   "moment": "^2.26.0"
 }

Y llegamos al problema

Vamos a crear una aplicación de ejemplo que va a consumir nuestra librería:

$ ng new example-app

Antes de instalar nuestra librería, veremos qué dependencias tiene nuestra aplicación y cuánto pesan de forma gráfica con Webpack Bundle Analyzer.

$ npm i -D webpack-bundle-analyzer

Añadimos el siguiente script al package.json.

"analyze": "ng build --prod --stats-json && webpack-bundle-analyzer ./dist/example-app/stats.json"

Al ejecutar este comando, se realiza una compilación para producción y se genera un stats.json que luego es recogido y visualizado por webpack-bundle-anlyzer.

Nuestro bundle principal incluye sólo Angular. El tamaño de nuestra aplicación actualmente es de 127.06KB.

Ahora vamos a instalar nuestra librería y ver cómo afecta al tamaño del bundle del proyecto.

Ya que estamos trabajando en este ejemplo con una librería en nuestro entorno local, debemos compilarla y copiar el dist/my-lib dentro de el node_modules de nuestra aplicación.

Importamos solo el módulo simple-texten app.component.module.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { SimpleTextModule } from 'node_modules/my-lib';
import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    SimpleTextModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Ejecutamos la aplicación y vemos que obtenemos un error en la terminal.

./node_modules/my-lib/fesm2015/my-lib.js:4:0-33 - Error: Module not found: Error: Can't resolve 'moment' in '/home/eogueta/example-app/node_modules/my-lib/fesm2015'

Aunque nuestra aplicación solo importa SimpleTextModule , el compilador de Angular nos pide instalar todas las peerDependencies definidas en my-lib, así que deberemos instalar moment.

$ npm i moment

Vamos a volver a lanzar el script de analyze:

Vemos que aunque no se esté usando directamente la librería moment, está incluida en nuestro bundle y el tamaño ha aumentado considerablemente, 506.74KB.

Esto se debe a que cuando construimos la librería se genera solo un chunk(my-lib.js) que contiene tanto SimpleTextComponent como CustomTimeComponent. Así que todavía obtenemos la librería moment incluso si solo importamos SimpleTextModule.

Vamos a implementar puntos de entrada secundarios

Hay varias razones por las que queremos usar puntos de entrada secundarios al diseñar nuestras librerías de Angular.

• Favorece el Tree-shaking. Dividir físicamente el código en un punto de entrada por feature aumenta la capacidad de esta técnica, proporcionando una versión más pequeña y eficiente.
• Puede facilitar el trabajo, el código está guardado en carpetas, con responsabilidades y estructuras claras para cada uno.
• Con herramientas como Nx o Madge, se puede trazar el gráfico de dependencia de la librería y ver qué depende de qué.

Para este ejemplo vamos a establecer custom-time como punto de entrada secundario siguiendo la estructura definida por ng-packagr, mientras que simple-text seguirá igual que hasta ahora.

De acuerdo con la documentación, esta sería la estructura:

my-lib
├── src
|   ├── lib
|   |    └── simple-text 
|   ├── public_api.ts (primary entry point)
|   └── *.ts
├── ng-package.json
├── package.json
└── custom-time(secondary entry point)
    ├── custom-time.component.ts
    ├── …
    ├── index.ts
    ├── public_api.ts
    └── package.json

Para trabajar con puntos de entrada secundarios, se necesita un mínimo de cuatro archivos por feature.

1. Agregamos index.ts, package.json y public_api.ts.

El index.ts solo está ahí para apuntar a public_api, que es útil durante las importaciones.

export * from './public_api';

Public_api.ts exporta todos los módulos y componentes de nuestro módulo.

/
 * Public API Surface of custom-time
 */
export * from './custom-time.component';
export * from './custom-time.module';

El package.json contiene configuraciones específicas de ng-packagr.

{
  "ngPackage": {
    "lib": {
      "entryFile": "public_api.ts"
    }
  },
  "peerDependencies": {
   // Lista de las peerDependecies de cada módulo
   "moment": "^2.29.1"
  }
}

2. Eliminamos la configuración que hemos especificado previamente en el archivo projects/my-lib/package.json, ya que la acabamos de definir en el nuevo fichero projects/my-lib/custom-time/package.json.
3. Borramos las exportaciones de custom-time de nuestro archivo principal public_apit.ts.

/
 * Public API Surface of my-lib
 */
export * from "./lib/simple-text/simple-text.component";
export * from "./lib/simple-text/simple-text.module";

4. Construimos la librería.

Terminamos con 2 chunks: my-lib.js, my-lib-custom-time.js.

Cada una de nuestros componentes/features obtiene su propio archivo .js, lo que significa que están incluidas en el paquete de su aplicación individualmente, favoreciendo la técnica de tree-shaking.

my-lib-custom-time.js ahora solo contiene el código relacionado con CustomTimeModule, y my-lib.js el código específico de SimpleTextModule.

Ejecutamos por última vez npm i analyze y podemos ver que el tamaño del bundle se ha reducido, 127.19KB.

5. Modificamos las rutas a la hora de importar.

Hay un ligero cambio a la hora de importar las rutas, ya que hemos movido nuestro custom-time del punto de entrada principal.

// Primary entry points
import { SimpleText } from 'my-lib';

// Secondary entry points
import { CustomTimeModule } from 'my-lib/custom-time';

Si la aplicación cliente solo importa el componente SimpleTextModule, deberíamos poder ejecutar la aplicación sin instalar moment.

Conclusión

Como hemos dicho antes, los puntos de entrada secundarios nos ofrecen una excelente manera de entregar nuestra librería en múltiples chunks.

Esto es lo que utiliza el equipo de Angular para las bibliotecas @angular/core y @angular/material. La mayoría de nosotros solamente usamos un pequeño subconjunto de los componentes de @angular/material y, al importar únicamente los módulos necesarios, el estilo o la lógica de otros componentes no necesitan incluirse innecesariamente en el paquete final de la aplicación.

Podemos sacar las siguientes conclusiones:

• Reduce la posibilidad de que la aplicación cliente se vea obligada a instalar todas las dependencias. Esto puede evitar parte de conflictos con otras librerías de componentes.
• Optimiza el tamaño de los bundles.
• Mejora la carga inicial de la aplicación.

Cosas a tener en cuenta:

• La actualización de importaciones al usar los puntos de entrada secundarios en aplicaciones que ya estén usando la librería.
• Si nuestro componente depende de interfaces, servicios o componentes ajenos, usar rutas absolutas.

Este artículo está basado en:

• Improve SPA performance by splitting your Angular libraries in multiple chunks
• Creating Secondary Entry Points for your Angular Library