Un grand nombre de fichiers générés pour chaque projet angulaire
je voulais lancer une simple application hello world pour Angular.
quand j'ai suivi les instructions dans le quickstart l'installation a créé 32.000 fichiers dans mon projet.
j'ai pensé que c'était une erreur ou j'ai manqué quelque chose, donc j'ai décidé d'utiliser angular-cli , mais après avoir mis en place le projet j'ai compté 41.000 fichiers.
Où ai-je mal tourné? Ai-je raté quelque chose de vraiment évident?
13 réponses
il n'y a rien de mal à votre configuration.
Angular (depuis la version 2.0) utilise les modules npm et les dépendances pour le développement. C'est la seule raison pour laquelle vous voyez un si grand nombre de dossiers.
une configuration de base D'Angular contient transpiler, typographie des dépendances qui sont essentiel à des fins de développement seulement.
une fois que vous avez terminé avec le développement, tout ce que vous aurez à faire est de regroupez cette demande.
après avoir fourni votre application, il n'y aura qu'un seul fichier bundle.js que vous pourrez ensuite déployer sur votre serveur.
'transpiler ' n'est qu'un compilateur, merci @omninonsense d'avoir ajouté ça.
Typical Angular2 Project
Package NPM (Fichiers de Développement) Monde Réel des Fichiers (Déploiement)
@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
* : bundled with @angular
[ voir cette regroupant un ensemble de processus et neArr; ]
il n'y a aucun problème avec votre configuration développement .
quelque chose qui ne va pas avec votre production configuration.
quand vous développez un "projet angulaire 2" ou "N'importe quel projet qui est basé sur JS" vous pouvez utiliser tous les fichiers, vous pouvez essayer tous les fichiers, vous pouvez importer tous les fichiers. Mais si vous voulez servir ce projet vous devez combiner tous les fichiers structurés et se débarrasser de fichiers inutiles.
Il y a beaucoup d'options pour combiner ces fichiers ensemble:
- Yui compresseur
- Google Closure Compiler
- Pour le côté serveur (je pense que c'est le meilleur) GULP
comme plusieurs personnes l'ont déjà mentionné: tous les fichiers de votre répertoire node_modules (localisation NPM pour les paquets) font partie de vos dépendances de projet (dites dépendances directes). En plus de cela, vos dépendances peuvent aussi avoir leurs propres dépendances et ainsi de suite. (Appelées dépendances transitives). Plusieurs dizaines de milliers de dossiers ne sont rien de spécial.
comme vous n'êtes autorisé à télécharger que 10'000 fichiers (voir les commentaires), j'utiliserais un moteur de bundler. Ce moteur regroupera tout votre JavaScript,CSS, HTML, etc. et créer un seul paquet (ou plus si vous les spécifiez). Votre index.html va charger ce paquet et c'est tout.
je suis un fan de webpack, donc ma solution webpack va créer un paquet application et un paquet fournisseur (pour l'application complète voir ici https://github.com/swaechter/project-collection/tree/master/web-angular2-example ):
index.html
<!DOCTYPE html>
<html>
<head>
<base href="/">
<title>Webcms</title>
</head>
<body>
<webcms-application>Applikation wird geladen, bitte warten...</webcms-application>
<script type="text/javascript" src="vendor.bundle.js"></script>
<script type="text/javascript" src="main.bundle.js"></script>
</body>
</html>
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));
}
avantages:
- version Complète en ligne (TS peluchage, la compilation, la minification etc.)
- 3 fichiers pour le déploiement -- > seulement quelques requêtes Http
inconvénients:
- de plus en Plus de temps de compilation
- non la la meilleure solution pour Http 2 projets (Voir l'avertissement)
Avertissement: C'est une bonne solution pour Http 1.* parce qu'il minimise la surcharge pour chaque requête Http. Vous n'avez qu'une demande de votre index.html et chaque paquet - mais pas pour 100-200 fichiers. Pour le moment, c'est le chemin à parcourir.
Http 2, d'un autre côté, essaie de minimiser la charge Http, donc elle est basée sur un protocole de flux. Ce flux est capable de communiquer dans les deux sens (Client < -- > Serveur) et en raison de cela un chargement de ressources plus intelligent est possible (vous ne chargez que les fichiers requis). Le flux élimine une grande partie de la charge Http (moins les allers-retours Http).
mais c'est la même chose Qu'avec IPv6: il faudra quelques années avant que les gens utilisent vraiment Http 2
vous devez vous assurer que vous déployez juste le dossier dist (abréviation pour distribuable) de votre projet généré par le Angular CLI . Cela permet à l'outil de prendre votre code source et ses dépendances et ne vous donne que ce dont vous avez besoin pour exécuter votre application.
cela étant dit, il y a eu un problème avec l'ouverture Angulaire de la CLI en ce qui concerne la production s'appuie par l'intermédiaire du `ng build --prod
Hier (2 Août), 2016) une version a été réalisée qui a permuté le mécanisme de construction de brocoli + systemjs à webpack qui traite avec succès les constructions de production.
basé sur ces étapes:
ng new test-project
ng build --prod
je vois un dist Taille du dossier de 1.1 MB à travers le 14 fichiers listés ici:
./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
Note actuellement pour installer la version webpack du cli angulaire, vous devez exécuter... npm install angular-cli@webpack -g
Angular lui-même a beaucoup de dépendances, et la version bêta de CLI téléchargements quatre fois plus de fichiers.
C'est comment créer un projet simple moins de fichiers ("seulement" fichiers 10K) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project /
semble comme personne n'a mentionné à L'avance la Compilation comme décrit ici: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
mon expérience avec Angular jusqu'à présent est que AoT crée les plus petites constructions avec presque pas de temps de chargement. Et le plus important, car la question ici est au sujet de - vous avez seulement besoin d'expédier quelques fichiers à la production.
cela semble être parce que le compilateur angulaire ne sera pas expédié avec les constructions de production que les gabarits sont compilés "à l'avance". Il est également très cool de voir votre balisage de modèle HTML transformé en instructions javascript qui serait très difficile de rétro-ingénierie dans le HTML original.
j'ai fait une vidéo simple où je montre la taille de téléchargement, le nombre de fichiers, etc. pour une application angulaire en dev vs aot build - que vous pouvez voir ici:
vous trouverez le code source de la démo ici:
https://github.com/fintechneo/angular2-templates
et - comme tous les autres l'ont dit ici - il n'y a rien de mal quand il y a beaucoup de fichiers dans votre environnement de développement. C'est ainsi avec toutes les dépendances qui viennent avec Angular, et beaucoup d'autres cadres modernes. Mais la différence ici est que lors de l'expédition à la production vous devriez être mesure de l'emballer dans quelques fichiers. De plus, vous ne voulez pas de tous ces fichiers de dépendances dans votre dépôt git.
en fait, ce N'est pas spécifique à un angle, cela se produit avec presque n'importe quel projet qui utilise L'écosystème NodeJs / npm pour son outillage.
ces projets se trouvent dans vos dossiers node_modules, et sont les dépendances de transition que vos dépendances directes doivent exécuter.
dans les modules d'écosystème de noeud sont généralement petits, ce qui signifie qu'au lieu de développer les choses nous-mêmes, nous avons tendance à importer la plupart de ce dont nous avons besoin sous la forme d'un module. Cela peut inclure des choses aussi petites comme la célèbre fonction gauche-pad, pourquoi l'écrire nous-mêmes si ce n'est comme un exercice ?
donc avoir beaucoup de fichiers est en fait une bonne chose, cela signifie que tout est très modulaire et les auteurs de modules ont fréquemment réutilisé d'autres modules. Cette facilité de modularité est probablement l'une des principales raisons pour lesquelles le nœud de l'écosystème a grandi si vite.
en principe, cela ne devrait pas causer de problème, mais il semble que vous rencontrez une application google limite du nombre de fichiers du moteur. Dans ce cas, je suggère de ne pas télécharger node_modules sur app engine.
au lieu de construire l'application localement et de télécharger sur google app engine seulement le fichier empaqueté, mais ne pas à la construction dans le moteur app lui-même.
si vous utilisez la nouvelle version de CLI angulaire, utilisez ng build --prod
il va créer dist dossier qui ont moins de fichiers et la vitesse du projet va augmenter.
aussi pour le test en local avec la meilleure performance de cli angulaire, vous pouvez utiliser ng serve --prod
si vous utilisez Angular CLI vous pouvez toujours utiliser -- drapeau minimal lorsque vous créez un projet
ng new name --minimal
je viens de l'exécuter avec le drapeau et il crée 24 600 fichiers et ng build --prod produit 212 KB dist folder
donc si vous n'avez pas besoin de fontaines d'eau dans votre projet ou si vous voulez juste tester rapidement quelque chose, je pense que c'est assez utile
Voici une comparaison de ce qui prend plus d'espace angulaire des projets.
si votre système de fichiers supporte des liens symboliques, alors vous pouvez au moins reléguer tous ces fichiers dans un dossier caché -- de sorte qu'un outil intelligent comme tree ne les affichera pas par défaut.
mv node_modules .blergyblerp && ln -s .blergyblerp node_modules
utiliser un dossier caché pour cela peut également encourager la compréhension qu'il s'agit de fichiers intermédiaires liés à la construction qui n'ont pas besoin d'être sauvegardés pour le contrôle de révision -- ou utilisés directement dans votre déploiement.
il n'y a rien de mal. Ce sont toutes les dépendances de noeuds que vous avez mentionnées dans le paquet.json.
il suffit d'être prudent si vous avez télécharger une partie du projet git hub, il pourrait avoir beaucoup d'autres dépendances qui ne sont pas réellement nécessaires pour angular 2 Premier hello world app :)
- assurez-vous d'avoir des dépendances angulaires -rxjs -Gulp - dactylographié - tslint -le panneau