Un grand nombre de fichiers générés pour chaque projet Angular

594

Je voulais lancer une simple application Hello World pour Angular.

Lorsque j'ai suivi les instructions du démarrage rapide officiel, l'installation a créé 32 000 fichiers dans mon projet.

J'ai pensé que c'était une erreur ou j'ai raté quelque chose, alors j'ai décidé d'utiliser angular-cli , mais après avoir mis en place le projet, j'ai compté 41 000 fichiers.

Où me suis-je trompé? Suis-je en train de manquer quelque chose de vraiment très évident?

javascript angular Moshe Shaham
la source
98
C'est normal pour les projets alimentés par NPM.
Everettss
115
@hendrix parce que mon déploiement (moteur d'application Google) n'autorise que 10 000 fichiers
Moshe Shaham
49
Pour toute personne curieuse du nombre de votes sur cette question et ses réponses, cela a fait la une de HN. news.ycombinator.com/item?id=12209028
ceejayoz
50
@hendrix - Je parie que vous validez également les fichiers .DS_Store dans git.
Martin Konecny
61
Je pense que "si votre application Hello World fonctionne, tout va bien" n'est pas une bonne philosophie à suivre, surtout pour quelqu'un qui apprend. L'OP a parfaitement raison de se demander pourquoi tant de fichiers ont été créés. L'exemple lui-même ne fait référence qu'à 5 fichiers. Et honnêtement, toute application qui a plus de fichiers qu'il n'y a de lettres dans sa sortie doit être interrogée.
Shawn

Réponses:

362

Il n'y a rien de mal avec votre configuration.

Angular (depuis la version 2.0) utilise des modules npm et des dépendances pour le développement. C'est la seule raison pour laquelle vous voyez un si grand nombre de fichiers.

Une configuration de base d'Angular contient des dépendances de transpilateur et de typage qui sont essentielles uniquement pour le développement.

Une fois le développement terminé, il vous suffit de regrouper cette application.

Après avoir regroupé votre application, il n'y aura qu'un seul bundle.jsfichier que vous pourrez ensuite déployer sur votre serveur.

'transpiler' n'est qu'un compilateur, merci @omninonsense pour l'avoir ajouté.

Bhushan Gadekar
la source
7
Il apporte également généralement les données de test et les tests et les outils de génération pour les dépendances et leurs dépendances, etc.
Benjamin Gruenbaum
63
Un "transpilateur" n'est qu'un compilateur.
omninonsense
32
mais compile dans une autre langue au lieu de coder en octets ou en code machine
Hunter McMillen
32
@HunterMcMillen Byte code et / ou Machine code est une autre langue. Le terme «transpilateur» n'a pas de signification supplémentaire que «compilateur».
Brandon Buck
76
En ce qui concerne toutes les personnes impliquées, je ne suis pas sûr que l'argument sémantique soit vraiment pertinent pour la question d'OP ^^
Dan Pantry
144 
                                Typical Angular2 Project

                       Fichiers de package NPM (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

[ voir ceci pour le processus de regroupement ⇗ ]

Ankit Singh
la source
24
Je suppose -3qu'on m'a donné pour ne pas avoir fait la somme, mais maintenant je l'ai :)
Ankit Singh
1
qu'entendez-vous par fichiers du monde réel?
yeahman
1
@yeahman "real world files" est le nombre de fichiers lorsque votre projet est déployé ou en production .
Maarti
Aussi la taille compte, seulement 3 fichiers, mais ils peuvent être énormes (pour le web)
pdem
51

Il n'y a rien de mal avec votre configuration de développement .

Quelque chose ne va pas avec votre configuration de production .

Lorsque vous développez un "projet Angular 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 ensemble:

ouragan
la source
2
Vous ne devriez pas (citation nécessaire) concaténer des fichiers ensemble sur le serveur. Tout au plus, j'utiliserais un transpilateur.
Dan Pantry
1
@DanPantry Transpilers sont des compilateurs de source à source. Je pense qu'ils ne peuvent changer que "X" en "JS". Le nombre de fichiers est le même.
ouragan du
1
..Oui, mais je ne suis pas sûr de votre point. Mon point est que vous ne devriez probablement pas essayer de minimiser le code du serveur (en concaténant des fichiers et en réduisant ainsi la taille des fichiers). Tout au plus, vous devriez utiliser Babel sur votre code si vous utilisez des fonctionnalités de saignement comme async / wait.
Dan Pantry
2
@DanPantry Je suis d'accord avec vous. Mais sur les commentaires, le questionneur dit "parce que mon déploiement (moteur d'application Google) n'autorise que 10K fichiers". Dans ces conditions, nous devons réduire le nombre de fichiers.
ouragan du
4
Je suis d'accord avec vous mais OP semble avoir un problème XY ici
Dan Pantry
30

Comme plusieurs personnes l'ont déjà mentionné: Tous les fichiers de votre répertoire node_modules (emplacement NPM pour les packages) font partie des dépendances de votre projet (soi-disant dépendances directes). En plus de cela, vos dépendances peuvent également avoir leurs propres dépendances et ainsi de suite, etc. (soi-disant dépendances transitives). Plusieurs dizaines de milliers de fichiers n'ont rien de spécial.

Parce que vous n'êtes autorisé à télécharger que 10'000 fichiers (voir commentaires), j'irais avec un moteur de bundler. Ce moteur regroupera tous vos JavaScript, CSS, HTML, etc. et créera un seul bundle (ou plus si vous les spécifiez). Votre index.html chargera ce bundle et c'est tout.

Je suis un fan de webpack, donc ma solution de webpack créera un bundle d'applications et un bundle de fournisseur (pour l'application complète, voir ici https://github.com/swaechter/project-collection/tree/master/web-angular2- exemple ):

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 de build complète (TS linting, compilation, minification, etc.)
  • 3 fichiers à déployer -> Seulement quelques requêtes Http

Désavantages:

  • Temps de construction plus long
  • Pas la meilleure solution pour les projets Http 2 (voir l'avertissement)

Avertissement: il s'agit d'une bonne solution pour Http 1. *, car elle minimise les frais généraux pour chaque demande Http. Vous avez seulement une demande pour votre index.html et chaque bundle - mais pas pour 100 à 200 fichiers. Pour le moment, c'est la voie à suivre.

Http 2, d'autre part, essaie de minimiser la surcharge Http, il est donc basé sur un protocole de flux. Ce flux est capable de communiquer dans les deux sens (Client <--> Serveur) et pour cette raison, un chargement de ressources plus intelligent est possible (Vous ne chargez que les fichiers requis). Le flux élimine une grande partie de la surcharge Http (moins d'allers-retours Http).

Mais c'est la même chose qu'avec IPv6: il faudra quelques années pour que les gens utilisent vraiment Http 2

swaechter
la source
1
Pas nécessaire cependant, puisque l'OP a mentionné l'utilisation angular-cliqui est déjà fournie avec un bundler (le même webpack suggéré).
mattarau
2
@mdentinho Oui, dans les versions plus modernes. Mais en 2016, SystemJS et CLI étaient la voie à suivre (heureusement, nous avons maintenant un webpack)
swaechter
21

Vous devez vous assurer que vous déployez simplement le dossier dist (abréviation de distribuable) à partir de votre projet généré par la CLI angulaire . 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 / était un problème avec la CLI angulaire en ce qui concerne les builds de production via `ng build --prod

Hier (2 août 2016), une version a été publiée, qui a fait passer le mécanisme de génération de broccoli + systemjs à webpack qui gère avec succès les versions de production.

Sur la base de ces étapes:

ng new test-project
ng build --prod

Je vois une disttaille de dossier de 1,1 Mo sur les 14 fichiers répertorié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 cli angulaire, vous devez exécuter ...npm install angular-cli@webpack -g

Brocco
la source
12

Il semble que personne n'ait mentionné la compilation anticipée comme décrit 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 plus petites versions avec presque aucun temps de chargement. Et le plus important, car la question est ici - vous n'avez besoin d'envoyer que quelques fichiers en 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 "Ahead of Time". Il est également très cool de voir votre balisage de modèle HTML transformé en instructions javascript qui seraient très difficiles à inverser dans le code HTML d'origine.

J'ai fait une vidéo simple où je dé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:

https://youtu.be/ZoZDCgQwnmQ

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 comme ça avec toutes les dépendances qui viennent avec Angular, et beaucoup d'autres frameworks modernes. Mais la différence ici est que lors de l'expédition vers la production, vous devriez être en mesure de l'intégrer dans quelques fichiers. De plus, vous ne voulez pas que tous ces fichiers de dépendance soient dans votre référentiel git.

Peter Salomonsen
la source
8

Ce n'est en fait pas spécifique à Angular, cela arrive avec presque tous les projets qui utilisent l'écosystème NodeJs / npm pour son outillage.

Ces projets se trouvent dans vos dossiers node_modules et sont les dépendances transitoires dont vos dépendances directes ont besoin pour s'exécuter.

Dans l'écosystème des nœuds, les modules sont généralement petits, ce qui signifie qu'au lieu de développer nous-mêmes les choses, nous avons tendance à importer la plupart de ce dont nous avons besoin sous la forme d'un module. Cela peut inclure de si petites choses comme la fameuse fonction du pavé gauche, pourquoi l'écrire nous-mêmes si ce n'est pas comme un exercice?

Donc, avoir beaucoup de fichiers est 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 l'écosystème de nœuds s'est développé si rapidement.

En principe, cela ne devrait pas poser de problème, mais il semble que vous rencontriez une limite de nombre de fichiers du moteur d'application Google. Dans ce cas, je suggère de ne pas télécharger node_modules vers le moteur d'application.

au lieu de cela, créez l'application localement et téléchargez dans le moteur d'application Google uniquement les fichiers fournis, mais pas dans le moteur d'application intégré lui-même.

Université angulaire
la source
8

Si vous utilisez la version la plus récente de angular cli, utilisez ng build --prod

Il créera un dossier dist qui aura moins de fichiers et la vitesse du projet augmentera.

Aussi pour tester en local avec les meilleures performances de cli angulaire que vous pouvez utiliser ng serve --prod

Jalay Oza
la source
6

si vous utilisez la CLI angulaire, vous pouvez toujours utiliser l'indicateur --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 --prodproduit un dossier dist de 212 Ko

Donc, si vous n'avez pas besoin de fontaines d'eau dans votre projet ou si vous voulez simplement tester rapidement quelque chose, je pense que c'est assez utile

SebOlens
la source
5

La création d'un nouveau projet avec angular cli récemment et le dossier node_modules était de 270 Mo, donc oui, c'est normal mais je suis sûr que la plupart des nouveaux développeurs du monde angulaire remettent cela en question et sont valides. Pour un nouveau projet simple, il serait judicieux de réduire les dépendances, peut-être un peu;) Ne pas savoir de quoi dépendent tous les packages peut être un peu énervant, en particulier pour les nouveaux développeurs essayant le cli pour la première fois. Ajoutez au fait que la plupart des didacticiels de base ne traitent pas des paramètres de déploiement pour obtenir les fichiers exportés uniquement nécessaires. Je ne crois pas que même le tutoriel proposé sur le site officiel angulaire parle de la façon de déployer le projet simple.

On dirait que le dossier node_modules est le coupable

maguy
la source
4

Voici une comparaison de ce qui prend plus de place dans les projets angulaires. entrez la description de l'image ici

Jagadesha NH
la source
3

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é - de sorte qu'un outil intelligent comme treene les affiche pas par défaut.

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

L'utilisation d'un dossier masqué à cet effet peut également encourager la compréhension qu'il s'agit de fichiers intermédiaires liés à la génération qui n'ont pas besoin d'être enregistrés dans le contrôle de révision - ou utilisés directement dans votre déploiement.

nobar
la source
Mon fil d'Ariane est devenu obsolète, mais voici à quoi il fait référence: web.archive.org/web/20150216184318/https://docs.npmjs.com/misc/…
nobar
2

Il n'y a rien de mal. Ce sont toutes les dépendances de noeud 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 y avoir beaucoup d'autres dépendances qui ne sont pas réellement requises pour la première application angular 2 hello world :)

  • assurez-vous d'avoir des dépendances angulaires -rxjs -gulp -typescript -tslint -docker
piyush anwekar
la source