Una delle cose che è stato introdotto in Angular 6 era la possibilità di creare e costruire librerie con la CLI angolare.

Quando ho usato questa funzione per la prima volta sono stato felice di quanto fosse semplice, poiché mentre era tecnicamente possibile creare librerie utilizzando versioni precedenti di Angular, era un’esperienza del tutto frustrante e triste.

In questo articolo, ti illustrerò gli elementi chiave dello sviluppo delle librerie angolari:

  • Casi d’uso comuni per le librerie angolari.
  • Creazione di una libreria utilizzando la CLI angolare.
  • Accelerare lo sviluppo di librerie angolari con npm link.
  • Pubblicazione della libreria.

Il codice demo completo per la libreria che creiamo può essere trovato qui.

Casi d’uso per le librerie angolari

Dalla mia esperienza, ci sono 2 casi d’uso comuni per le librerie angolari:

  1. Creazione di una libreria di componenti riutilizzabili per la condivisione tra applicazioni.
  2. Creazione di funzionalità di livello di servizio condiviso-ad es. un client per lavorare con un’origine dati esterna come un’API.

Mentre ci sono molti casi in cui una libreria angolare è adatta per un progetto, vale la pena considerare se il tuo caso d’uso è uno di questi, in quanto introduce un sovraccarico di manutenzione. Ricorda, puoi sempre scrivere funzionalità come parte di un modulo angolare condiviso all’interno dell’applicazione ed estrarlo in una libreria quando necessario.

Creazione di un progetto di libreria angolare

Creeremo una libreria angolare, così come un’applicazione demo per consumare questa libreria. Possiamo crearli con i seguenti comandi:

ng new example-component-library --create-application=falsecd example-component-libraryng generate library example-component-libraryng generate application example-component-library-app

L’utilizzo del flag --create-application=false impedisce ad Angular di creare un’applicazione con il nome ‘example-component-library’, che è il nome che vogliamo dare alla libreria stessa e non all’applicazione di test, come spiegato qui.

Se ora guardiamo all’interno dello spazio di lavoro che abbiamo appena creato, possiamo vedere che c’è una cartella projects contenente una sottocartella per ciascuna libreria (esempio-componente-libreria) e l’applicazione (esempio-componente-libreria-app) che abbiamo appena generato. C’è anche una terza cartella contenente un progetto di test e2e, che possiamo ignorare.

passiamo ora a costruire la nostra libreria e vedere cosa succede:

ng build --project=example-component-library

Se andiamo a guardare nella cartella dist, vedremo che la nostra biblioteca è stata costruita e che all’interno della cartella di compilazione abbiamo un certo numero di diverse cartelle contenenti l’applicazione in diversi formati di modulo adatto per i diversi consumatori, nonché una cartella contenente Dattiloscritto definizioni.

  • bundle-Formato modulo UMD.
  • esm5 – formato del modulo che utilizza principalmente es5, ma anche la sintassi di importazione / esportazione da es6.
  • esm2015 – formato del modulo che utilizza es2015 / es6.
  • fesm5 – versione appiattita di esm5.
  • fesm2015-versione appiattita dipeerDependencies esm2015.
  • definizioni lib – TypeScript per la libreria.

Questo formato è chiamato Angular Package Format, ed è il formato utilizzato come output di ng-packagr, lo strumento che Angular CLI utilizza per transpilare le librerie.

Strutturare il progetto della libreria angolare

Il contenuto della libreria è attualmente simile a questo:

Struttura delle cartelle Iniziale

Innanzitutto, elimina i file esistentiexample-component-library modulo, componente e servizio – non ne abbiamo bisogno.

Successivamente aggiungeremo un componente, una pipe e una direttiva. Seguiremo uno schema di aggiunta di un componente per modulo: ciò consentirà a un’applicazione che consuma di importare solo i moduli della libreria a cui è interessata e quindi che tutti gli altri moduli vengano agitati durante il processo di compilazione. Consiglio vivamente di farlo, poiché farà davvero la differenza per le dimensioni dei pacchetti di applicazioni man mano che la libreria cresce.

ng generate module components/foong generate component components/foong generate module pipes/barng generate pipe pipes/bar/barng generate module directives/bazng generate directive directives/baz/baz

Dopo aver fatto questo la nostra biblioteca dovrebbe avere la seguente struttura di cartelle:

Struttura di Cartelle Finale

naturalmente, questa struttura può essere regolata in funzione su di voi o il vostro team di preferenza, ma le cose importanti da tenere a mente sono:

  • Avere un componente per ogni modulo, per consentire un albero di agitazione della inutilizzati moduli/componenti.

    L’eccezione a questo è che i componenti che sono sempre usati insieme dovrebbero essere tenuti nello stesso modulo, ad es. Se si stavano implementando le schede, un TabGroupComponent e TabItemComponent vivrebbero nello stesso modulo.

  • Cerca di evitare o limitare l’uso delle importazioni di barrel all’interno di una libreria angolare

    In Angular 6 ci sono problemi con le importazioni di barrel nelle librerie e la build AOT angolare. Questi problemi sembrano essere risolti in Angular 7, ma mi imbatto regolarmente in problemi confusi dovuti alle importazioni di barili e quindi sostengo questa raccomandazione di utilizzare solo 1 livello di importazioni di barili (o semplicemente evitarli del tutto).

poi si deve aggiungere tutti i componenti che abbiamo creato a exports del suo modulo:

import { CommonModule } from '@angular/common';import { FooComponent } from './foo.component';import { NgModule } from '@angular/core';@NgModule({ declarations: , imports: , exports: })export class FooModule { }

aggiornare public_api.ts per esportare tutti i file nella libreria che si desidera esporre a un’applicazione molto:

/* * Public API Surface of example-component-library */export * from './lib/components/foo/foo.module';export * from './lib/components/foo/foo.component';export * from './lib/pipes/bar/bar.module';export * from './lib/pipes/bar/bar.pipe';export * from './lib/directives/baz/baz.module';export * from './lib/directives/baz/baz.directive';

Ora tutto quello che dobbiamo fare è ricostruire la libreria, e sarà pronto a consumare la libreria da un’applicazione.

ng build --project=example-component-library

Consumare la nostra libreria angolare

Durante lo sviluppo il modo migliore per consumare la nostra libreria è usare npm link. Ciò ci consentirà di collegare simbolicamente da una directory nella cartella dei moduli node della nostra applicazione consumante all’applicazione compilata nella cartella dist della libreria.

cd dist/example-component-librarynpm link

Possiamo collegare un progetto angolare a questa libreria da qualsiasi punto della nostra macchina locale. Dalla cartella principale del progetto:

npm link example-component-library

Se ora eseguiamo la libreria con il flag watch, e allo stesso tempo eseguiamo ng serve in un’altra finestra di terminale.

ng build --project=example-component-libraryng serve

Questo ci permetterà di sviluppare un’applicazione e (una o più) librerie collegate contemporaneamente, e vedere l’applicazione ricompilare con ogni modifica al codice sorgente della libreria.

In Produzione

Per la produzione, pubblicheremo la nostra libreria su npm, quindi la faremo installare nell’applicazione usandonpm install.

In primo luogo, è necessario creare un account npm. Ora il login dalla riga di comando:

npm login

Dalla cartella principale del progetto:

cd dist/example-component-librarynpm publish

il pacchetto è ora pubblicato sul npm (pubblicamente), e si può installare con l’aggiunta della nostra applicazione package.json dipendenze e l’esecuzione di npm install:

"dependencies": { ... "example-component-library": "~0.0.1"}

Biblioteca dipendenze

Se la tua biblioteca ha delle dipendenze, allora queste devono essere specificati come dependencies o peerDependencies nel package.json della tua libreria stessa (e non il package.json nella root del progetto). Ad esempio, nel caso della nostra libreria semplice, abbiamo solo le seguenti dipendenze:

"peerDependencies": { "@angular/common": "^7.1.0", "@angular/core": "^7.1.0"}

Angular è specificato come peerDependencyinvece di dependency per evitare che l’applicazione consumante installi più versioni contrastanti di Angular. Questo articolo ha alcune buone informazioni su peerDependencies e quando usarli.

Conclusione

Abbiamo visto come possiamo creare una libreria di componenti angolari che può essere utilizzata da più applicazioni angolari diverse, così come come possiamo lavorare con le librerie in sviluppo e pubblicarle per la produzione. Di seguito ho elencato le risorse che ho trovato utili per conoscere personalmente le librerie angolari e per scrivere questo articolo.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.