Numero enorme di file generati per ogni progetto Angular

Volevo avviare una semplice app Hello World per Angular.

Quando ho seguito le istruzioni nel quickstart ufficiale, l’installazione ha creato 32.000 file nel mio progetto.

Ho pensato che fosse un errore o mi mancava qualcosa, quindi ho deciso di usare angular-cli , ma dopo aver impostato il progetto ho contato 41.000 file.

Dove ho sbagliato? Mi sto perdendo qualcosa di veramente ovvio?

Non c’è niente di sbagliato nella tua configurazione.

Angolare (dalla versione 2.0) utilizza i moduli npm e le dipendenze per lo sviluppo. Questa è l’unica ragione per cui vedi un numero così grande di file.

Una configurazione di base di Angular contiene transpiler, dipendenze tipizzazioni che sono essenziali solo per scopi di sviluppo.

Una volta terminato lo sviluppo, tutto ciò che devi fare è raggruppare questa applicazione.

Dopo aver raggruppato l’applicazione, sarà disponibile un solo file bundle.js che sarà quindi ansible distribuire sul server.

‘transpiler’ è solo un compilatore, grazie a @omninonsense per averlo aggiunto.

  Typical Angular2 Project 

File del pacchetto NPM (sviluppo) File del mondo reale (distribuzione)

 @angular 3,236 1 rxJS 1,349 1* core-js 1,341 2 typings 1,488 0 gulp 1,218 0 gulp-typescript 1,243 0 lite-server 5,654 0 systemjs-builder 6,470 0 __________________________________________________________________ Total 21,999 3 

* : in bundled with @angular

[ vedi questo per il processo di raggruppamento ⇗ ]

Non c’è niente di sbagliato nella configurazione di sviluppo .

Qualcosa non va nella tua configurazione di produzione .

Quando sviluppi un “Progetto Angolare 2” o “Qualsiasi Progetto basato su JS” puoi usare tutti i file, puoi provare tutti i file, puoi importare tutti i file. Ma se vuoi servire questo progetto devi COMBINARE tutti i file strutturati e liberarti di file inutili.

Ci sono molte opzioni per combinare questi file insieme:

  • Compressore YUI
  • Google Closure Compiler
  • Per lato server (penso che sia il migliore) GULP

Come molte persone hanno già menzionato: tutti i file nella directory node_modules (posizione NPM per i pacchetti) fanno parte delle dipendenze del progetto (chiamate dipendenze dirette). In aggiunta a ciò, le tue dipendenze possono anche avere le loro dipendenze e così via, ecc. (Cosiddette dipendenze transitive). Diversi diecimila file non sono niente di speciale.

Dato che puoi caricare solo 10.000 file (vedi commenti), andrei con un motore bundler. Questo motore raggruppa tutti i tuoi JavaScript, CSS, HTML ecc. E crea un singolo bundle (o più se li specifichi). Il tuo index.html caricherà questo pacchetto e il gioco è fatto.

Sono un fan del webpack, quindi la mia soluzione webpack creerà un bundle di applicazioni e un bundle di fornitori (per l’applicazione completa funzionante, vedere qui https://github.com/swaechter/project-collection/tree/master/web-angular2- esempio ):

index.html

     Webcms   Applikation wird geladen, bitte warten...     

webpack.config.js

 var webpack = require("webpack"); var path = require('path'); var ProvidePlugin = require('webpack/lib/ProvidePlugin'); var CommonsChunkPlugin = require('webpack/lib/optimize/CommonsChunkPlugin'); var UglifyJsPlugin = require('webpack/lib/optimize/UglifyJsPlugin'); /* * Configuration */ module.exports = { devtool: 'source-map', debug: true, entry: { 'main': './app/main.ts' }, // Bundle configuration output: { path: root('dist'), filename: '[name].bundle.js', sourceMapFilename: '[name].map', chunkFilename: '[id].chunk.js' }, // Include configuration resolve: { extensions: ['', '.ts', '.js', '.css', '.html'] }, // Module configuration module: { preLoaders: [ // Lint all TypeScript files {test: /\.ts$/, loader: 'tslint-loader'} ], loaders: [ // Include all TypeScript files {test: /\.ts$/, loader: 'ts-loader'}, // Include all HTML files {test: /\.html$/, loader: 'raw-loader'}, // Include all CSS files {test: /\.css$/, loader: 'raw-loader'}, ] }, // Plugin configuration plugins: [ // Bundle all third party libraries new CommonsChunkPlugin({name: 'vendor', filename: 'vendor.bundle.js', minChunks: Infinity}), // Uglify all bundles new UglifyJsPlugin({compress: {warnings: false}}), ], // Linter configuration tslint: { emitErrors: false, failOnHint: false } }; // Helper functions function root(args) { args = Array.prototype.slice.call(arguments, 0); return path.join.apply(path, [__dirname].concat(args)); } 

vantaggi:

  • Linea completa (TS linting, compiling, minification ecc.)
  • 3 file per la distribuzione -> Solo poche richieste Http

svantaggi:

  • Più alto tempo di costruzione
  • Non è la soluzione migliore per progetti Http 2 (vedi disclaimer)

Dichiarazione di non responsabilità: questa è una buona soluzione per Http 1. *, poiché minimizza il sovraccarico per ogni richiesta Http. Hai solo una richiesta per il tuo index.html e ogni pacchetto – ma non per 100 – 200 file. Al momento, questa è la strada da percorrere.

Http 2 d’altra parte cerca di minimizzare l’overhead Http, quindi è basato su un protocollo di streaming. Questo stream è in grado di comunicare in entrambe le direzioni (Client <-> Server) e, a causa di ciò, è ansible un caricamento più intelligente delle risorse (si caricano solo i file richiesti). Lo stream elimina gran parte dell’overhead Http (meno round trip Http).

Ma è lo stesso di IPv6: ci vorranno alcuni anni prima che le persone utilizzino davvero Http 2

È necessario assicurarsi di implementare la cartella dist (abbreviazione per distribuibile) dal progetto generato da Angular CLI . Ciò consente allo strumento di prendere il tuo codice sorgente e le sue dipendenze e ti fornisce solo ciò di cui hai bisogno per eseguire la tua applicazione.

Detto questo, c’è / è stato un problema con la CLI di Angular riguardo alle build di produzione tramite `ng build –prod

Ieri (2 agosto 2016) è stata rilasciata una versione che ha cambiato il meccanismo di build da broccoli + systemjs a webpack che gestisce con successo i build di produzione.

Basato su questi passaggi:

 ng new test-project ng build --prod 

Sto vedendo una dimensione della cartella dist di 1,1 MB tra i 14 file elencati qui:

 ./app/index.js ./app/size-check.component.css ./app/size-check.component.html ./favicon.ico ./index.html ./main.js ./system-config.js ./tsconfig.json ./vendor/es6-shim/es6-shim.js ./vendor/reflect-metadata/Reflect.js ./vendor/systemjs/dist/system.src.js ./vendor/zone.js/dist/zone.js 

Nota Attualmente per installare la versione webpack del cli angular, è necessario eseguire … npm install [email protected] -g

Angular ha molte dipendenze e la versione beta della CLI scarica quattro volte più file.

Ecco come creare un progetto semplice con meno file (“solo” file 10K) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/

Sembra che nessuno abbia menzionato la compilazione Ahead-of-Time come descritto qui: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html

La mia esperienza con Angular finora è che AoT crea le build più piccole senza quasi nessun tempo di caricamento. E la cosa più importante, in questo caso, riguarda la questione: è sufficiente spedire alcuni file alla produzione.

Questo sembra essere dovuto al fatto che il compilatore Angolare non verrà spedito con i build di produzione man mano che i template vengono compilati “Ahead of Time”. È anche molto interessante vedere il markup del modello HTML trasformato in istruzioni javascript che sarebbe molto difficile da decodificare nel codice HTML originale.

Ho realizzato un semplice video in cui mostro le dimensioni del download, il numero di file ecc. Per un’app Angular in Dev vs AoT build, che puoi vedere qui:

https://youtu.be/ZoZDCgQwnmQ

Qui troverai il codice sorgente per la demo:

https://github.com/fintechneo/angular2-templates

E – come tutti gli altri hanno detto qui – non c’è niente di sbagliato quando ci sono molti file nel tuo ambiente di sviluppo. È così che funziona tutte le dipendenze fornite da Angular e molti altri framework moderni. Ma la differenza qui è che quando si spedisce alla produzione si dovrebbe essere in grado di comprimerlo in pochi file. Inoltre non vuoi tutti questi file di dipendenza nel tuo repository git.

Questo in realtà non è specifico Angolare, accade con quasi tutti i progetti che utilizzano l’ecosistema NodeJs / npm per i suoi strumenti.

Questi progetti si trovano all’interno delle cartelle node_modules e sono le dipendenze transititve che devono essere eseguite dalle dipendenze dirette.

Nel nodo l’ecosistema dei moduli è di solito piccolo, il che significa che invece di sviluppare noi stessi tendiamo a importare la maggior parte di ciò di cui abbiamo bisogno sotto forma di modulo. Questo può includere cose così piccole come la famosa funzione del tasto sinistro, perché scrivere da soli se non come esercizio?

Quindi avere un sacco di file è davvero una buona cosa, significa che tutto è molto modulare e gli autori dei moduli spesso hanno riutilizzato altri moduli. Questa facilità di modularità è probabilmente uno dei motivi principali per cui l’ecosistema dei nodes è cresciuto così velocemente.

In linea di principio questo non dovrebbe causare alcun problema, ma sembra che tu abbia incontrato un limite di conteggio dei file del motore dell’app Google. In questo caso, suggerisco di non caricare node_modules nel motore dell’app.

invece, crea l’applicazione localmente e carica su google app engine solo i filesn in bundle ma non alla build nel motore dell’app stesso.

Se si utilizza la versione più recente di ng build --prod cli, utilizzare ng build --prod

Creerà la cartella dist con meno file e aumenterà la velocità del progetto.

Anche per test in locale con le migliori prestazioni di cli angolari puoi usare ng serve --prod

se si utilizza la CLI angular, è sempre ansible utilizzare il flag –minimal quando si crea un progetto

 ng new name --minimal 

Ho appena eseguito con il flag e crea 24 600 file e ng build --prod produce 212 KB dist cartella

Quindi se non hai bisogno di fontane d’acqua nel tuo progetto o vuoi solo testare velocemente qualcosa, penso che sia abbastanza utile

Ecco un confronto tra ciò che prende più spazio nei progetti angolari. inserisci la descrizione dell'immagine qui

Se il tuo file system supporta collegamenti simbolici, puoi almeno rebind tutti questi file in una cartella nascosta, in modo che uno strumento intelligente come la tree non li visualizzi per impostazione predefinita.

 mv node_modules .blergyblerp && ln -s .blergyblerp node_modules 

L’utilizzo di una cartella nascosta per questo può anche incoraggiare la comprensione che si tratta di file intermedi relativi alla build che non devono essere salvati nel controllo di revisione o utilizzati direttamente nella distribuzione.

Non c’è niente di sbagliato. Queste sono tutte le dipendenze dei nodes che hai menzionato nel pacchetto.json.

Basta fare attenzione se hai scaricato alcuni dei progetti git hub, potrebbe avere molte altre dipendenze che non sono realmente necessarie per la prima app del mondo h angular 2 🙂

  • assicurati di avere dipendenze angolari -rxjs -gulp -typescript -tslint -docker