javascript - estructura - crear proyecto angular 6
Gran cantidad de archivos generados para cada proyecto angular (14)
Quería iniciar una aplicación sencilla hello world para Angular.
Cuando seguí las instrucciones en el quickstart oficial, la instalación creó 32,000 archivos en mi proyecto.
Pensé que esto era un error o me perdí algo, así que decidí usar angular-cli , pero después de configurar el proyecto conté 41,000 archivos.
¿Qué hice mal? ¿Me estoy perdiendo algo realmente muy obvio?
Angular tiene muchas dependencias, y la versión beta de CLI descarga cuatro veces más archivos.
Así es como crear un proyecto simple tendrá menos archivos ("solo" archivos 10K) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/
Como varias personas ya mencionaron: Todos los archivos en su directorio node_modules (ubicación NPM para paquetes) son parte de las dependencias de su proyecto (las llamadas dependencias directas). Además de eso, sus dependencias también pueden tener sus propias dependencias, etc. (llamadas dependencias transitivas). Varios diez mil archivos no son nada especial.
Debido a que solo puedes subir 10''000 archivos (ver comentarios), iría con un motor de paquetes. Este motor agrupará todos sus JavaScript, CSS, HTML, etc. y creará un solo paquete (o más si los especifica). Su index.html cargará este paquete y listo.
Soy un fanático de webpack, por lo que mi solución de paquete web creará un paquete de aplicaciones y un paquete de proveedores (para ver la aplicación de trabajo completa, consulte aquí 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));
}
Ventajas:
- Línea de compilación completa (TS linting, compilación, minificación, etc.)
- 3 archivos para implementación -> Solo unas pocas solicitudes Http
Desventajas
- Mayor tiempo de construcción
- No es la mejor solución para proyectos Http 2 (Ver descargo de responsabilidad)
Descargo de responsabilidad: esta es una buena solución para Http 1. *, ya que minimiza la sobrecarga para cada solicitud Http. Solo tiene una solicitud para su index.html y cada paquete, pero no para 100-200 archivos. Por el momento, este es el camino a seguir.
Http 2, por otro lado, intenta minimizar la sobrecarga de Http, por lo que se basa en un protocolo de transmisión. Este flujo puede comunicarse en ambas direcciones (Cliente <--> Servidor) y, por eso, es posible una carga de recursos más inteligente (Solo carga los archivos necesarios). La secuencia elimina gran parte de la sobrecarga Http (menos viajes de ida y vuelta Http).
Pero es lo mismo que con IPv6: tomará algunos años hasta que la gente realmente use Http 2
Crear un nuevo proyecto con angular cli recientemente y la carpeta node_modules era de 270 mb, así que sí, esto es normal, pero estoy seguro de que la mayoría de los nuevos desarrolladores del mundo angular cuestionan esto y es válido. Para un nuevo proyecto simple, tendría sentido reducir las dependencias quizás un poco;) No saber de qué dependen todos los paquetes puede ser un poco desconcertante, especialmente para los nuevos desarrolladores que prueban el cli por primera vez. Además, la mayoría de los tutoriales básicos no discuten la configuración de implementación para obtener los archivos exportados que solo se necesitan. No creo que incluso el tutorial ofrecido en el sitio web oficial angular habla sobre cómo implementar el proyecto simple.
Debe asegurarse de que solo está implementando la carpeta dist (abreviatura de distribuible) de su proyecto generado por la angular-cli . Esto permite que la herramienta tome su código fuente y sus dependencias y solo le brinde lo que necesita para ejecutar su aplicación.
Dicho esto, hay / hubo un problema con la CLI angular en lo que respecta a las compilaciones de producción a través de `ng build --prod
Ayer (2 de agosto de 2016) se realizó un lanzamiento que cambió el mecanismo de compilación de broccoli + systemjs a webpack que maneja con éxito las compilaciones de producción.
Basado en estos pasos:
ng new test-project
ng build --prod
Veo un tamaño de carpeta
dist
de
1.1 MB
en los
14 archivos
enumerados aquí:
./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
Actualmente para instalar la versión webpack del angular cli, debe ejecutar ...
npm install angular-cli@webpack -g
En realidad, esto no es específico de Angular, sucede con casi cualquier proyecto que use el ecosistema NodeJs / npm para sus herramientas.
Esos proyectos están dentro de sus carpetas node_modules y son las dependencias de tránsito que sus dependencias directas necesitan ejecutar.
En el nodo, los módulos del ecosistema suelen ser pequeños, lo que significa que, en lugar de desarrollar cosas nosotros mismos, tendemos a importar la mayor parte de lo que necesitamos bajo la forma de un módulo. Esto puede incluir cosas tan pequeñas como la famosa función de teclado izquierdo, ¿por qué escribirlo nosotros mismos si no como un ejercicio?
Por lo tanto, tener una gran cantidad de archivos es algo bueno, significa que todo es muy modular y los autores de módulos frecuentemente reutilizan otros módulos. Esta facilidad de modularidad es probablemente una de las principales razones por las que el ecosistema de nodos creció tan rápido.
En principio, esto no debería causar ningún problema, pero parece que te encuentras con un límite de conteo de archivos del motor de la aplicación de Google. En ese caso, sugiero no cargar node_modules al motor de la aplicación.
en su lugar, cree la aplicación localmente y cargue en el motor de la aplicación de Google solo los archivos incluidos, pero no lo haga en el motor de la aplicación.
No hay nada malo con su configuración de desarrollo .
Algo está mal con su configuración de producción .
Cuando desarrolla un "Proyecto Angular 2" o "Cualquier proyecto basado en JS", puede usar todos los archivos, puede probar todos los archivos, puede importar todos los archivos. Pero si desea servir este proyecto, necesita COMBINAR todos los archivos estructurados y deshacerse de los archivos inútiles.
Hay muchas opciones para combinar estos archivos:
- Compresor YUI
- Compilador de cierre de Google
- Para el lado del servidor (creo que es lo mejor) GULP
No hay nada malo con su configuración.
Angular (desde la versión 2.0) utiliza módulos npm y dependencias para el desarrollo. Esa es la única razón por la que está viendo una cantidad tan enorme de archivos.
Una configuración básica de Angular contiene transpiler, dependencias de tipificación que son esenciales solo para fines de desarrollo.
Una vez que haya terminado con el desarrollo, todo lo que tendrá que hacer es agrupar esta aplicación.
Después de agrupar su aplicación, solo habrá un archivo
bundle.js
que podrá implementar en su servidor.
''transpiler'' es solo un compilador, gracias @omninonsense por agregar eso.
No hay nada malo. Estas son todas las dependencias de nodo que ha mencionado en package.json.
Solo tenga cuidado si ha descargado parte del proyecto git hub, podría tener muchas otras dependencias que no son realmente necesarias para la aplicación angular 2 first hello world :)
- asegúrese de tener dependencias angulares -rxjs -gulp -typescript -tslint -docker
Parece que nadie ha mencionado la compilación anticipada como se describe aquí: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
Mi experiencia con Angular hasta ahora es que AoT crea las compilaciones más pequeñas casi sin tiempo de carga. Y lo más importante, ya que la pregunta aquí es: solo necesita enviar algunos archivos a producción.
Esto parece deberse a que el compilador Angular no se enviará con las compilaciones de producción, ya que las plantillas se compilan "por adelantado". También es genial ver el marcado de su plantilla HTML transformado en instrucciones de JavaScript que serían muy difíciles de aplicar ingeniería inversa en el HTML original.
Hice un video simple donde demuestro el tamaño de descarga, la cantidad de archivos, etc. para una aplicación Angular en desarrollo vs AoT build, que puedes ver aquí:
Encontrará el código fuente de la demostración aquí:
https://github.com/fintechneo/angular2-templates
Y, como todos los demás dijeron aquí, no hay nada de malo cuando hay muchos archivos en su entorno de desarrollo. Así es con todas las dependencias que vienen con Angular y muchos otros marcos modernos. Pero la diferencia aquí es que cuando se envía a producción, debería poder empaquetarlo en unos pocos archivos. Además, no desea todos estos archivos de dependencia en su repositorio git.
Si está utilizando la versión más nueva de angular cli, use
ng build --prod
Creará una carpeta dist que tendrá menos archivos y aumentará la velocidad del proyecto.
También para probar en local con el mejor rendimiento de cli angular, puede usar
ng serve --prod
Si su sistema de archivos admite enlaces simbólicos, entonces al menos puede relegar todos estos archivos a una carpeta oculta, para que una herramienta inteligente como el
tree
no los muestre de manera predeterminada.
mv node_modules .blergyblerp && ln -s .blergyblerp node_modules
El uso de una carpeta oculta para esto también puede alentar la comprensión de que estos son archivos intermedios relacionados con la compilación que no necesitan guardarse para el control de revisión, o usarse directamente en su implementación.
si usa CLI angular, siempre puede usar el indicador mínimo cuando crea un proyecto
ng new name --minimal
Lo acabo de ejecutar con la bandera y crea 24 600 archivos y
ng build --prod
produce una carpeta de 212 KB
Entonces, si no necesita fuentes de agua en su proyecto o simplemente desea probar rápidamente algo, creo que es bastante útil
Typical Angular2 Project
NPM Package Files (Desarrollo) Archivos del mundo real (Implementación)
@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