Grand nombre de fichiers générés pour chaque projet Angular
Je voulais lancer une application simple Hello World pour Angular.
Lorsque j'ai suivi les instructions de la version officielle quickstart , l'installation a créé 32 000 fichiers dans mon projet.
J'ai pensé que c'était une erreur ou quelque chose m'avait manqué, alors j'ai décidé d'utiliser angular-cli , mais après avoir configuré le projet, j'ai compté 41 000 fichiers.
Où me suis-je trompé? Est-ce que je manque quelque chose de vraiment évident?
Il n'y a rien de mal avec votre configuration.
Angular (depuis la version 2.0) utilise les modules et les dépendances npm pour le développement. C'est la seule raison pour laquelle vous voyez un si grand nombre de fichiers.
Une configuration de base de Angular contient transpiler, des dépendances de typages qui sont essentielles à des fins de développement uniquement.
Une fois le développement terminé, il ne vous reste plus qu'à regrouper cette application.
Après avoir regroupé votre application, un seul fichier bundle.js sera déployé sur votre serveur.
'transpiler' est juste un compilateur, merci @omninonsense de l'avoir ajouté.
_ Typical Angular2 Project
_NPM Package Fichiers (Développement) Fichiers du monde réel (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
Il n'y a rien de mal avec votre configuration développement .
Quelque chose ne va pas avec votre configuration de production .
Lorsque vous développez un "projet angulaire 2" ou "tout projet 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 vous débarrasser des fichiers inutiles.
Il existe de nombreuses options pour combiner ces fichiers:
- Compresseur YUI
- compilateur Google Closure
- Pour le côté serveur (je pense que c'est mieux) GULP
Comme plusieurs personnes l'ont déjà mentionné: Tous les fichiers de votre répertoire node_modules (emplacement NPM des packages) font partie des dépendances de votre projet (dites dépendances directes). En plus de cela, vos dépendances peuvent également avoir leurs propres dépendances, etc. (dépendances dites transitives). Plusieurs dizaines de milliers de fichiers n'ont rien de spécial.
Étant donné que vous n'êtes autorisé à télécharger que 10 000 fichiers (voir les commentaires), j'utiliserais un moteur de regroupement. Ce moteur regroupera tous vos codes JavaScript, CSS, HTML, etc. et créera un seul ensemble (ou plus si vous les spécifiez). Votre index.html chargera cet ensemble et le tour est joué.
Je suis un fan de Webpack, ma solution Webpack va donc créer un ensemble d'applications et un ensemble de fournisseurs (pour l'application complète, voir ici https://github.com/swaechter/project-collection/tree/master/ exemple-web-angular2 ):
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:
- Ligne complète de construction (lintégration TS, compilation, minification, etc.)
- 3 fichiers pour le déploiement -> seulement quelques requêtes HTTP
Désavantages:
- Temps de construction plus long
- Pas la meilleure solution pour les projets Http 2 (Voir avertissement)
Clause de non-responsabilité: Il s'agit d'une bonne solution pour Http 1. *, car elle minimise le temps système pour chaque requête Http. Vous avez seulement une demande pour votre index.html et chaque ensemble, mais pas pour 100 à 200 fichiers. Pour le moment, c'est la voie à suivre.
Http 2, d’autre part, essaie de minimiser la surcharge de Http, donc il est basé sur un protocole de flux. Ce flux est capable de communiquer dans les deux sens (client <-> serveur) et, par conséquent, un chargement de ressources plus intelligent est possible (vous ne chargez que les fichiers requis). Le flux élimine une grande partie des frais généraux 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 ne faites que déployer le dossier dist (abréviation de distribuable) de votre projet généré par Angular CLI . Cela permet à l'outil de prendre votre code source et ses dépendances et de ne vous donner que ce dont vous avez besoin pour exécuter votre application.
Cela étant dit, il y a un problème avec le Angular CLI en ce qui concerne les versions de production via `ng build --prod
Hier (2 août 2016), une version validant le mécanisme de génération de broccoli + systemjs à webpack , qui gère correctement les versions de production.
Basé sur ces étapes:
ng new test-project
ng build --prod
Je vois une taille de dossier dist de 1,1 Mo sur les 14 fichiers énuméré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
Remarque Actuellement, pour installer la version Webpack du angular cli, 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 la CLI télécharge quatre fois plus de fichiers.
Voici comment créer un projet simple qui contiendra moins de fichiers ("uniquement" des fichiers 10K) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/
On dirait que personne n'a mentionné la compilation anticipée telle que décrite ici: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
Mon expérience avec Angular jusqu'à présent est que l'AoT crée les versions les plus petites sans temps de chargement. Et le plus important, car la question ici est de savoir qu'il vous suffit d'envoyer quelques fichiers à la production.
Cela semble être dû au fait que le compilateur Angular ne sera pas livré avec les versions de production, car les modèles sont compilés "à l’avance". Il est également très intéressant de voir votre balise de modèle HTML transformée en instructions javascript qui seraient très difficiles à inverser dans le code HTML d'origine.
J'ai réalisé une vidéo simple dans laquelle je montre la taille du téléchargement, le nombre de fichiers, etc. pour une application Angular dans la version dev vs AoT - 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’ya rien qui cloche quand il y a beaucoup de fichiers dans votre environnement de développement. C'est comme ça avec toutes les dépendances fournies avec Angular et beaucoup d'autres frameworks modernes. Mais la différence ici est que lors de la livraison en production, vous devriez pouvoir le ranger dans quelques fichiers. De plus, vous ne voulez pas que tous ces fichiers de dépendance se trouvent dans votre référentiel git.
En réalité, ceci n'est pas spécifique à Angular, cela se produit avec presque tous les projets qui utilisent l'écosystème NodeJs/npm pour ses outils.
Ces projets se trouvent dans vos dossiers node_modules et constituent les dépendances transitoires que vos dépendances directes doivent exécuter.
Dans l'écosystème de nœuds, les modules sont généralement petits, ce qui signifie qu'au lieu de développer nous-mêmes, nous avons tendance à importer la plupart de ce dont nous avons besoin sous la forme d'un module. Cela peut inclure de petites choses comme la célèbre fonction left-pad, pourquoi l'écrire nous-mêmes, sinon comme exercice?
Donc, avoir beaucoup de fichiers est une bonne chose, cela veut dire que tout est très modulaire et que 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 l'écosystème de nœuds s'est développé si rapidement.
En principe, cela ne devrait poser aucun problème, mais il semble que vous rencontriez un nombre limite de fichiers dans le moteur d'application Google. Dans ce cas, je suggère de ne pas télécharger node_modules sur le moteur d'applications.
construisez plutôt l'application localement et chargez dans le moteur d'application Google uniquement les fichiers fournis, mais ne le faites pas dans le moteur d'application intégré lui-même.
Si vous utilisez la version plus récente de angularcli, utilisez ng build --prod
Cela créera un dossier dist qui aura moins de fichiers et la vitesse du projet augmentera.
Vous pouvez également utiliser ng serve --prod pour tester en local avec les meilleures performances de angular cli.
si vous utilisez Angular CLI, vous pouvez toujours utiliser l'option --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 génère un dossier de 212 Ko
Donc, si vous n'avez pas besoin d'eau de fontaine 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 de place dans angular projets. 
Si votre système de fichiers prend en charge les liens symboliques, vous pouvez au moins reléguer tous ces fichiers dans un dossier caché, afin qu'un outil intelligent tel que tree ne les affiche pas par défaut.
mv node_modules .blergyblerp && ln -s .blergyblerp node_modules
L'utilisation d'un dossier caché à cette fin peut également aider à comprendre qu'il s'agit de fichiers intermédiaires liés à la construction qui n'ont pas besoin d'être enregistrés dans 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 nœuds que vous avez mentionnées dans le package.json.
Faites juste attention si vous avez téléchargé 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 première application bonjour du monde :)
- assurez-vous que vous avez angular dépendances -rxjs -gulp -TypeScript -tslint -docker
Création d'un nouveau projet avec angular cli récemment et le dossier node_modules était de 270 mb, alors oui, c'est normal, mais je suis sûr que la plupart des nouveaux développeurs de la question angular sont valides . Pour un nouveau projet simple, il serait peut-être logique de réduire un peu les dépendances;) Ne pas savoir en quoi dépendent tous les paquets peut être un peu gênant, en particulier pour les nouveaux développeurs qui essaient le client pour la première fois. Ajoutez à cela que les didacticiels les plus élémentaires ne décrivent pas les paramètres de déploiement pour obtenir uniquement les fichiers exportés. Je ne crois pas que même le tutoriel proposé sur le site officiel angular explique comment déployer ce projet simple.
