Angular-cli: Se tarda una eternidad en la "optimización de activos de fragmentos del 92%", ¿se puede almacenar en caché o deshabilitar?

Esta es la salida de Webpack, no una impresionante.

Los activos aquí no se refieren a los activos de la CLI de Angular. Se refieren a archivos de fragmentos de Webpack. Aquí es donde ocurre una gran parte del procesamiento de archivos de Webpack. Es por eso que es largo.

Hay una discusión muy larga sobre todo el tema de la velocidad de compilación aquí https://github.com/angular/angular-cli/issues/1980.

Sin embargo, lo que está viendo es ciertamente una locura (y muy inusual según la experiencia con muchos proyectos), independientemente de este mensaje específico.

¿Puede proporcionar la línea de comando utilizada para realizar la compilación?

@clydin Estoy usando ng serve --proxy-config proxy.config.json --aot --watch false --verbose o ng build --aot .

Aunque también estoy compilando sin Ahead of Time (AoT)... pero mi proyecto es grande...

Sin AoT, el tiempo de construcción se reduce considerablemente:

40207ms building modules                                                                   
293ms sealing
17ms optimizing
1ms basic module optimization 
0ms module optimization 
1000ms advanced module optimization
58ms basic chunk optimization       
0ms chunk optimization 
4ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms module reviving 
60ms module order optimization
9ms module id optimization 
0ms chunk reviving 
11ms chunk order optimization
51ms chunk id optimization
186ms hashing
4ms module assets processing 
368ms chunk assets processing
10ms additional chunk assets processing
0ms recording 
0ms additional asset processing 
11447ms chunk asset optimization
106ms asset optimization
784ms emitting
Hash: 52784939e9af576aa850
Version: webpack 2.2.1
Time: 54662ms

Pero obtengo más errores con AoT habilitado, por eso quiero usarlo mientras construyo.

Ahora necesito expandir el tamaño de la memoria del montón del nodo para compilar con AoT. Ahora utiliza 5,5 GB de RAM para compilar con AoT... :(

node --max_old_space_size=8192 ./node_modules/.bin/ng build --aot
Hash: 2013b35185f990a8e57f                                                                 
Time: 373584ms
chunk    {0} main.bundle.js, main.bundle.js.map (main) 12 MB {4} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 278 kB {5} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 751 kB {5} [initial] [rendered]
chunk    {3} scripts.bundle.js, scripts.bundle.js.map (scripts) 362 kB {5} [initial] [rendered]
chunk    {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 4.44 MB [initial] [rendered]
chunk    {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

+1, experimentando el mismo problema con --aot habilitado en CLI 1.0.0 y Angular 4.
Se tarda más de 3 minutos en compilar, la mayor parte está en 92% chunk asset optimization .

> ng serve --proxy-config proxy.conf.json --open --aot

** NG Live Development Server is running on http://localhost:4200 **
 12% building modules 21/25 modules 4 active ...ode_modules/style-loader/addStyles.jswebpack: wait until bundle finished: /
 94% asset optimizationwebpack: wait until bundle finished: /
Hash: b569b293e489e6c84a01
Time: 192655ms
chunk    {0} 0.chunk.js, 0.chunk.js.map 3.84 MB {1} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {1} 1.chunk.js, 1.chunk.js.map 2.23 MB {0} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {2} 2.chunk.js, 2.chunk.js.map 1.91 MB {0} {1} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {3} 3.chunk.js, 3.chunk.js.map 1.73 MB {0} {1} {2} {4} {5} {6} {7} {9} [rendered]
chunk    {4} 4.chunk.js, 4.chunk.js.map 1.74 MB {0} {1} {2} {3} {5} {6} {7} {9} [rendered]
chunk    {5} 5.chunk.js, 5.chunk.js.map 1.63 MB {0} {1} {2} {3} {4} {6} {7} {9} [rendered]
chunk    {6} 6.chunk.js, 6.chunk.js.map 1.6 MB {0} {1} {2} {3} {4} {5} {7} {9} [rendered]
chunk    {7} 7.chunk.js, 7.chunk.js.map 1.57 MB {0} {1} {2} {3} {4} {5} {6} {9} [rendered]
chunk    {8} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 231 kB {13} [initial] [rendered]
chunk    {9} main.bundle.js, main.bundle.js.map (main) 179 kB {12} [initial] [rendered]
chunk   {10} styles.bundle.js, styles.bundle.js.map (styles) 576 kB {13} [initial] [rendered]
chunk   {11} scripts.bundle.js, scripts.bundle.js.map (scripts) 858 kB {13} [initial] [rendered]
chunk   {12} vendor.bundle.js, vendor.bundle.js.map (vendor) 1.72 MB [initial] [rendered]
chunk   {13} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]
webpack: Compiled successfully.

Sin --aot toma alrededor de 20 segundos.

Por ahora, no se puede compilar AoT y el equipo de Angular lo sabe. Aparentemente, están trabajando duro para hacerlo más rápido, pero siempre será significativamente (?) Más lento que simplemente pasar por el compilador de TypeScript.

Otra cosa que hace que la compilación sea extremadamente lenta (y usa mucha memoria) es tener habilitados los mapas fuente. En la mayoría de las situaciones, compilamos y desarrollamos sin los mapas fuente habilitados debido a lo lentas que se vuelven las reconstrucciones cuando están habilitados. No es lo ideal, pero se debe trabajar mucho en Webpack (especialmente) para hacerlos rápidos.

Wepack tiene algunas opciones de mapas de origen más baratas, pero no funcionan correctamente con Typescript, así que tampoco vaya allí.

Actualmente, AOT no está diseñado para usarse durante el desarrollo. Es en esencia una optimización de producción similar en algunos aspectos a la minificación o compresión.

@clydin que he usado para detectar errores de arranque solo presentes durante la ejecución (no la compilación). Antes de escribir pruebas es muy útil.

@clydin Tengo el problema del 92% al usar ng test, lo que significa que Karma no detecta cambios y tengo que reiniciar ng test cada vez. ¿Es el mismo problema o solo una coincidencia?

El 92% asset optimizing es una cosa del paquete web, sí. Secundo lo que dijeron @hccampos y @clydin : no es recomendable usar --aot para el desarrollo en este momento, ya que será demasiado lento. El equipo de Angular está trabajando arduamente para que sea lo suficientemente rápido para usarlo en todo momento, pero aún no hemos llegado allí.

@DrMueller ng test actualmente no utiliza algunas optimizaciones que tenemos en ng build y eso hace que las reconstrucciones sean lentas. Eso se rastrea en https://github.com/angular/angular-cli/issues/5423 , con una solución tentativa en https://github.com/angular/angular-cli/pull/6160.

Tuve el mismo problema de rendimiento y vi que al agregar --sourcemap=false a ng serve y ng test las cosas empezaron a funcionar mucho más rápido.

ng serve --sourcemap=false

@SchnWalter Esto reduce significativamente de 11 segundos a 6 segundos. Increíble. ¿Algún efecto en el desarrollo al desactivar el mapa fuente?

¿Algún efecto en el desarrollo al desactivar el mapa fuente?

@cevarief
Si desea usar debugger; o explorar el seguimiento de la pila, entonces obtendrá el mapeo de líneas de código fuente poco confiables.
Lo cual es aceptable cuando no desea depurar. De lo contrario, si desea depurar, simplemente enciéndalo con sourcemaps nuevamente.

nuestra compilación AOT tarda 26 segundos. ¿Hay alguna manera de obtener una idea de lo que se está construyendo en este paso?

AOT lleva algo de tiempo, pero solo lo uso para compilaciones de producción, por lo que está bien.
ng serve toma un poco de tiempo (menos que AOT) inicialmente, pero luego es bastante rápido en las reconstrucciones.
El único problema que todavía tengo es que cuando cambio alguna definición de interfaz, no la recoge. Se reconstruirá pero luego se quejará de que algún campo no existe en la interfaz. Tienes que eliminarlo y ejecutar ng serve nuevamente para que los cambios funcionen.

Deshabilitar el mapa fuente hizo las cosas mucho más rápidas para mí,

ng servir --sourcemap=falso

Supongo que debería haber sido más específico ya que esto es parte del comando ng test del angular cli. Es realmente frustrante ejecutar pruebas unitarias y tener que esperar 30 segundos...

Ese ng test lento de 36 segundos mencionado anteriormente estaba usando la versión 1.0 de CLI. Usar el último 1.3.0-rc.5 es aún más lento. 2 veces el tiempo del paso chunk asset optimization . Con esta versión, se necesitan 56 segundos antes de que se puedan ejecutar las pruebas unitarias. Si activa build-optimization , tardará nada menos que 98 segundos... Necesitamos una forma de desactivarlo para ng-test y/u obtener una salida más detallada durante la fase chunk asset .

"ng serve --sourcemap=false" redujo el tiempo de reconstrucción de 20 segundos a 2 segundos en mi caso.

Mi compilación AOT tarda 362 segundos en el motor de cómputo de Google, 1 CPU, 6.5 Gig Ram. Agregar más CPU realmente no ha hecho ninguna diferencia.

En mi computadora personal, toma alrededor de 210 segundos construir la aplicación, lo cual es extraño, porque es un i7-3660 de 5 años (OC a 4.2ghz, pero aún así).

Honestamente, esto hace que la implementación sea frustrante, especialmente cuando obtiene un error de montón de Javascript y ha estado esperando 6 minutos para descubrirlo.

Aparte, creo que ng build con aot debería establecer la memoria del nodo por usted, o realmente debería agregar esto a su package.json predeterminado solo para facilitar las cosas a las personas:

"build-prod": "node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot",

Optimización de activos de fragmentos del 92 %

Ya estoy ordenando algunos! 😂

Si se encuentra con el mismo problema aquí, se detiene en un 94 %. ¿Podemos personalizar la camiseta @gangsthub? :sonreír:

Debe dejar de quejarse, actualizar su Angular CLI, corregir sus advertencias de compilación de AOT y usar AOT también para la depuración, ya que ahora admite la depuración:

ng serve --aot

Y trate de mantenerse al día con los lanzamientos de Angular CLI, las cosas mejoran día a día.

PD ¡Gracias a todos los que trabajan en esto!

EDITAR: con AOT, la compilación inicial es lenta, las compilaciones posteriores son mucho más rápidas.

Uso Angular 6 con un proyecto empresarial extremadamente grande.

ng build --aot --prod

Tiempo: 780178ms

Demasiado tiempo

@ bluefire2121 --aot lo hace un poco más lento, pero vale la pena para el usuario final, en mi opinión. ¿Tienes muchos bienes? (solo curiosidad por saber dónde está el cuello de botella)

ng serve --aot es un gran consejo de @SchnWalter

@gangsthub Tengo 6,06 MB de activos. Inicialmente, había creado una API CDN para conectarme a mis activos, pero tuve que desechar ese plan debido a las restricciones de CORS en nuestra intranet. Los activos deben existir en el mismo dominio del servidor. .gitignore y .tfignore incluyen node_modules, por lo que no estoy seguro de qué podría estar causando el problema. Tenemos muchos componentes, servicios, clases y plantillas, pero la compilación inicial no debería ser tan larga.

Me pregunto si este problema de "92 % de optimización de activos de fragmentos" está relacionado con esta regresión de rendimiento en uglify-es (ahora terser ). También estuve viendo "92%" durante mucho tiempo como resultado de ese problema.

Para mí, parchee manualmente "node_modulesuglify-es\lib\compress.js" como dijo @mlwilkerson para el problema https://github.com/fabiosantoscode/terser/issues/50 funciona: 26 segundos para compilar --prod --aot

Puedes usar esta bandera mientras compilas:
ng servir --source-mapa=falso

Se tarda 10 segundos en compilar ahora, mientras que antes tardaba 32 segundos.
source-map solo se usa para la depuración. Entonces, si no usa el depurador, puede deshabilitarlo y compilarlo.

@spmsupun esa sugerencia fue muy buena: pero recomendaría usar: --build-optimizer=true junto con --vendor-chunk=true . También agregué el --extract-css=true

ng build --aot --extract-css=true --build-optimizer=true --vendor-chunk=true --prod

El trozo principal va (con solo --aot --prod ) de 2.37MB a 734kB 😊

Además, el tiempo, que es lo que estábamos hablando, disminuye un poco: de 120 a 70 segundos.

este es el problema del ram, necesitas aumentar tu ram o liberar ram.

@mrhrao No es un "problema de ram" para mí.

Estoy tratando de compilar y servir con fines de depuración. También me gustaría AOT, pero puedo vivir sin él.

Estoy usando configuration en mi angular.json para establecer variables de entorno para mi máquina de prueba:

configurations": {
        "production": {
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.prod.ts"
            }
          ],
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": false,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true
        },
        "dev": {
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.dev.ts"
            }
          ],
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": true,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true
        }
      }
    },

Se tarda una eternidad (minutos) en compilar. Mi línea de comando es:
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve ui -c dev --aot

Tengo versiones actuales de todos los paquetes angulares (a partir del 2018-07-12) "@angular/cli": "^6.0.8"

Tengo 562 archivos en mi carpeta src .

¿Algunas ideas?

@filipesilva ¿Podemos reabrir este tema? ¿O dirigirme a uno bueno que esté abierto?

Me quedo atascado en 92% chunk asset optimization UglifyJSPlugin aparentemente para siempre (lo dejé durante la noche y nunca pasó).

Esto parece ser solo un problema cuando se usa WSL (Subsistema de Windows para Linux), ya que puedo compilarlo adecuadamente en contenedores Docker o incluso usando git-bash.

También estoy experimentando esto con un nuevo proyecto Angular 6. SOLO toma una eternidad cuando construyo para producción con --prod . Cuando no hago una compilación de producto, va súper rápido y sin problemas. ¿Alguien se ha dado cuenta de esto?

También tengo este problema. Se tarda 25 minutos en construir el proyecto. Fue 2-3 minutos antes.

Mismo problema al implementar la aplicación Angular 6 en Heroku usando ng build --prod
Quedarse atascado en el 92% de la optimización de activos de fragmentos UglifyJSPlugin durante al menos 5 minutos

mismo problema con la producción de paquetes web

Esto se está convirtiendo en una broma corriente. Atascado en 92% chunk asset optimization UglifyJSPlugin en gitlab mientras que es _bastante_ aceptable cuando se construye localmente, incluso con la marca --prod.

me tomó 1 hora hacer una compilación de producto
estamos usando angular 4.4.6 y mi comando de compilación es
node --max_old_space_size=6048 node_modules/@angular/cli/bin/ng build --prod --aot --env=azureDev --extract-css --preserve-symlinks --named-chunks

Ojalá hubiera un reconocimiento del equipo de Angular sobre este problema y una fecha tentativa de solución

Lo mismo aquí, quedarse atascado en el 92% de optimización de activos de fragmentos UglifyJSPlugin durante al menos 3 minutos

@meghma , este artículo está marcado como cerrado. ¿Quizás abrir un nuevo número?

@filipesilva ¿Puedes ayudarnos con esto?

Tuve el mismo problema y encontré algunos detalles en el sitio web impresionante de fuentes:

https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

La solución que he usado actualmente es crear un archivo patch.js con el siguiente contenido:

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {/g, 'compress: { collapse_vars: false,');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

Y haz referencia a él en el paquete.json

...

  "scripts": {
    "postinstall": "node patch.js",
...

tendrá que ejecutar node/yarn install para que se active.

HTH

@lucboutier No funciona en mi caso.

@lucboutier tampoco tuvo suerte aquí, lo único que funciona por ahora es deshabilitar la compresión por completo, lo cual no es una opción en mi caso

Hay una solución disponible para las compilaciones de hilos , usando un alias para reemplazar uglify-es con terser , que incluye la solución de la causa raíz para el problema de collpase_vars . Esa podría ser una opción para algunas personas aquí hasta que esa solución llegue a las dependencias de Webpack 4.

¿Alguien ha intentado eso para un angular-cli ?

(ACTUALIZACIÓN 26 de septiembre de 2018: este cambio _no_ llegará a las dependencias de Webpack 4, pero la hoja de ruta de Webpack 5 incluye un movimiento a terser que tiene la solución).

Se las arregló para que funcionara anulando explícitamente todas las configuraciones de compresión con sus valores predeterminados de acuerdo con los documentos (aunque todavía tengo que descubrir por qué funciona).

Una actualización para el guión de @lucboutier :

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {[^}]*}/g, 'compress: {\n' +
    '           arrows: true,\n' +
    '           booleans: true,\n' +
    '           collapse_vars: true,\n' +
    '           comparisons: true,\n' +
    '           computed_props: true,\n' +
    '           conditionals: true,\n' +
    '           dead_code: true,\n' +
    '           drop_console: false,\n' +
    '           drop_debugger: true,\n' +
    '           ecma: wco.supportES2015 ? 6 : 5,\n' +
    '           evaluate: true,\n' +
    '           expression: false,\n' +
    '           global_defs: {},\n' +
    '           hoist_funs: false,\n' +
    '           hoist_props: true,\n' +
    '           hoist_vars: false,\n' +
    '           if_return: true,\n' +
    '           // Workaround known uglify-es issue\n' +
    '           // See https://github.com/mishoo/UglifyJS2/issues/2949#issuecomment-368070307\n' +
    '           inline: wco.supportES2015 ? 1 : 3,\n' +
    '           join_vars: true,\n' +
    '           keep_classnames: false,\n' +
    '           keep_fargs: true,\n' +
    '           keep_fnames: false,\n' +
    '           keep_infinity: false,\n' +
    '           loops: true,\n' +
    '           negate_iife: true,\n' +
    '           // PURE comments work best with 3 passes.\n' +
    '           // See https://github.com/webpack/webpack/issues/2899#issuecomment-317425926.\n' +
    '           passes: buildOptions.buildOptimizer ? 3 : 1,\n' +
    '           properties: true,\n' +
    '           pure_funcs: null,\n' +
    '           pure_getters: buildOptions.buildOptimizer,\n' +
    '           reduce_funcs: true,\n' +
    '           reduce_vars: true,\n' +
    '           sequences: true,\n' +
    '           side_effects: true,\n' +
    '           switches: true,\n' +
    '           toplevel: false,\n' +
    '           top_retain: null,\n' +
    '           typeofs: true,\n' +
    '           unsafe: false,\n' +
    '           unsafe_arrows: false,\n' +
    '           unsafe_comps: false,\n' +
    '           unsafe_Function: false,\n' +
    '           unsafe_math: false,\n' +
    '           unsafe_methods: false,\n' +
    '           unsafe_proto: false,\n' +
    '           unsafe_regexp: false,\n' +
    '           unsafe_undefined: false,\n' +
    '           unused: true,\n' +
    '           warnings: false\n' +
    '         }');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

Para evitar el problema de la memoria, ng build aún debe ejecutarse en un contexto con mayor memoria disponible

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build ...

Espero que todavía ayude a alguien.

Actualmente experimentando este problema.

Angular CLI: 6.1.3
Node: 8.11.3
OS: win32 x64
Angular: 6.1.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.7.3
@angular-devkit/build-angular     0.7.3
@angular-devkit/build-optimizer   0.7.3
@angular-devkit/build-webpack     0.7.3
@angular-devkit/core              0.7.3
@angular-devkit/schematics        0.7.3
@angular/cli                      6.1.3
@ngtools/webpack                  6.1.3
@schematics/angular               0.7.3
@schematics/update                0.7.3
rxjs                              6.2.2
typescript                        2.7.2
webpack                           4.9.2

La solución de @egervari de:

"build-prod": "node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot",

Hace que la compilación pase de ~ 12 minutos a 2 segundos para mí.

@mlwilkerson : Trabajó con angular-cli. Gracias por la pista :+1:

@mlwilkerson : terser está funcionando muy bien: redujo significativamente los tiempos de compilación de> 50 minutos a <2 minutos para mí.

Esto es lo que hice (más una solución temporal):

# Add terser to dependencies
npm install terser --save-dev

# Remove uglify-js
rm -r node_modules/uglify-js
rm -r node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es

# Symlink to terser (which is fully compatible)
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglify-js
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es

@konstantinkoeppe gracias por el guión. el tiempo de construcción disminuyó en un 30%

konstantinkoeppe es la única solución que encontré en este hilo. Gran trabajo compañero.

Intentando construir esto en un contenedor docker. No tuve suerte con ninguno de los enfoques anteriores. Siempre cuelga al 92%.

¿Por qué se cerró este tema?

FYI: estoy usando el shell de Linux en Windows. Cuando uso el shell de Linux, es terriblemente lento (ni siquiera esperé a terminar).

Cuando uso powershell, se construye en 10 segundos.

https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/272

Encontré esta solución node --max_old_space_size=4096 node_modules/.bin/webpack -p --progress --profile Con suerte, esto ayudará a alguien.

@anupy ¿ Algún consejo sobre lo que hacemos con esa línea y cómo ayudará? No veo la conexión, todavía.

También tuve un tiempo de construcción muy lento de hasta 20 minutos. Pero en mi caso, tuve que optimizar las importaciones. Por lo tanto, la sacudida del árbol no tendrá mucho que hacer. Especialmente la optimización de las importaciones de fontawesome a importaciones profundas resolvió el problema del tiempo de compilación. Tal vez esto ayude a alguien.

Puedo confirmar que pasar a terser ha funcionado como lo describe @mlwilkerson , los pasos cortos y simples son:

npm i terser --save-dev

y luego

  "resolutions": {
    "uglify-es": "npm:terser"
  }

En su paquete.json

Mi construcción se redujo a menos de un minuto. (de más de varios minutos)

Tenga en cuenta también que la versión 7.0 de la CLI ahora usa terser de forma predeterminada. No son necesarios pasos adicionales.

Hola, solucioné este problema en mi PC de trabajo usando powershell en lugar de wsl. No sé si alguno de ustedes está usando el subsistema Linux, pero la CPU está bloqueada, no se puede paralelizar, por lo que usar PowerShell para compilar y servir aumentó mis tiempos.
Estoy hablando de: ctr+c after +40minutes a -2minutes .

¿Alguien puede decir por qué se ha cerrado este tema? Nuestra compilación de lanzamiento todavía lleva literalmente años en completarse. Siempre se cuelga en "Optimización de activos de fragmentos del 92 %".

Mi problema con esto se resolvió cuando terminé de usar el subsistema Ubuntu como administrador predeterminado de npm, no se paraleliza y esta tarea dura para siempre.
Me mudé a powershell.

¿Alguien puede decir por qué se ha cerrado este tema? Nuestra compilación de lanzamiento todavía lleva literalmente años en completarse. Siempre se cuelga en "Optimización de activos de fragmentos del 92 %".

@rbluethl , el 92% se trata de dónde se usaba UglifyJSPlugin. Actualizar a Angular 7 ayudará porque se usa un complemento diferente (Terser). Además, es posible que se esté quedando sin RAM. A mí me pasó con un servidor de 4GB al principio.

Todavía estoy con Angular 6. Esto es lo que estoy usando en producción en estos días:

> ng build --prod --extract-css=true --sourceMap=false --aot --build-optimizer=true --vendor-chunk=true

Y en desarrollo:

> ng serve --progress --open --sourceMap=true --optimization=false --aot --vendorChunk=true

• --optimization=false deshabilita la minificación usando UglifyJSPlugin, lo cual te ayudará.
• Y observe que se recomienda usar --aot en ambos procesos.
• --prod --aot reducirá el tiempo de construcción y el tamaño de salida ;). Ver mi comentario anterior: https://github.com/angular/angular-cli/issues/5775#issuecomment -402745894

- prod es - - ya no.

@gangsthub Probé --optimization=false en nuestro proyecto interno (que generalmente tarda 2:40 minutos en construirse). No trajo ninguna mejora. De hecho, aumentó el tiempo de compilación a 2:44.

Sin embargo, es importante tener en cuenta que estamos usando ng build --watch=true , no ng serve (su ejemplo). Tal vez la bandera solo sea válida para el subcomando serve .

Tienes razón, @DiegoMGar. --prod incluye --aot según la documentación.
@Dzhuneyt , es posible que no esté entendiendo su problema correctamente: ¿por qué está usando build + watch en desarrollo? No creo que sea para lo que está pensado. Build crea un paquete de production de forma predeterminada: https://angular.io/cli/build

@gangsthub porque tenemos un proyecto bastante complejo que requiere NGINX, Apache y reenviar estos dos a un directorio estático donde se puede acceder al código fuente de la interfaz (/dist). El "servidor ligero" de Angular no funciona.

Esto parece ser un problema mayor si habilita los mapas de origen. La siguiente configuración/comandos funcionan en Angular 7:

Configuración de SourceMap en angular.json

"sourceMap": {
    "hidden": true,
    "scripts": true,
    "styles": true
}

Usando el siguiente comando:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --es5BrowserSupport=true --prod=true --aot --build-optimizer=true --output-hashing all --extract-css=true --output-path=./tmp/dist

Se mantendrá en el 92 % durante un tiempo, pero finalmente aumentará.

Bueno, en mi caso, el proceso estaba terminando por falta de memoria.
Habilité el intercambio en el servidor de compilación y luego funciona perfectamente bien.

¿Podemos abrir este problema de nuevo?

Recibí este error cuando incorporé la ventana acoplable en Windows, cambié el límite de memoria a 4 GB en la configuración de virtualbox y funciona para mí.

Creo que nos enfrentamos a este problema, ya que la API de metadatos de Reflect ahora forma parte del proceso de compilación de angular, por lo que tendremos más entrada de cálculo, pero la aplicación será más rápida. GB ram realmente no es suficiente para construir un proyecto angular complejo en estos días, incluso con 4 GB de intercambio...

Será realmente útil si tenemos salida de caché de la compilación para que podamos adjuntar este caché al contenedor de Docker y solo se compilarán los cambios en lugar de toda la aplicación. Sí, algunos dirán que desencadenará más problemas con el caché, pero depende de que bien escrito ;)

Angular-cli 7.1.2 usando solo terser, eliminado uglify. El problema sigue siendo el mismo. No entiendo por qué este tema está cerrado.

MacBook Pro 2017 (configuración máxima). En la computadora portátil de mi colega, tomó como 6 veces más.
Angular-cli 7.3.8
ng compilación --prod --aot

Fecha: 2019-05-22T14:17:10.865Z
Hash: c46f53e11f136ebcccaf
Tiempo: 252612ms
fragmento {0} common.afc1032bf3c4b8275ad0.js (común) 13,3 kB [renderizado]
fragmento {1} 1.a15ce621172a345de3fb.js () 17,7 kB [renderizado]
fragmento {2} 2.2f5ed724319337a8e568.js () 35,4 kB [renderizado]
fragmento {3} 3.60e537acc75ac058b27c.js () 18,4 kB [renderizado]
fragmento {4} runtime.579f6773a2b26d94db5d.js (tiempo de ejecución) 3,55 kB [entrada] [renderizado]
fragmento {5} 5.347c1f3685ec3ba82396.js () 22,5 kB [renderizado]
fragmento {6} main.9181a4cb2e65813f8502.js (principal) 4,3 MB [inicial] [renderizado]
fragmento {7} polyfills.7b3fb56fc82120d2029f.js (polyfills) 61,7 kB [inicial] [renderizado]
fragmento {8} estilos.268c785458aec578546e.css (estilos) 326 kB [inicial] [renderizado]
fragmento {9} 9.cf61d9ddb5622467f3f3.js () 31 kB [renderizado]
fragmento {10} 10.0cd72c145b577e65cf28.js () 5,3 kB [renderizado]
fragmento {11} 11.9dfeb2dd944fe80224cf.js () 98,6 kB [renderizado]
fragmento {12} 12.8aa7c4e6cdd6615f2014.js () 7,07 kB [renderizado]
fragmento {13} 13.8999e86ed963ef839840.js () 29 kB [renderizado]
fragmento {14} 14.8cf84a196f45ed341ce0.js () 5,31 kB [renderizado]
fragmento {15} 15.d313fabcfc0d0a86d25d.js () 18,7 kB [renderizado]
fragmento {16} 16.3bb6114bc3541835e4a0.js () 6,38 kB [renderizado]
fragmento {17} 17.7c5dbc1fbe2336666081.js () 18,4 kB [renderizado]
fragmento {18} 18.709082325c1f7cbbd1b9.js () 5,32 kB [renderizado]
fragmento {19} 19.f75679cd15753e642ace.js () 5,32 kB [renderizado]
fragmento {20} 20.ead991d5d12b29a5c046.js () 23,2 kB [renderizado]
fragmento {21} 21.b19be2caaa1019c1d5a8.js () 5,32 kB [renderizado]
fragmento {22} 22.b8710a26bd79a8f2d9d5.js () 6,36 kB [renderizado]
fragmento {23} 23.31688d97f4b9eb3e8b7d.js () 5,31 kB [renderizado]
fragmento {24} 24.4ddab1995018ff5b7989.js () 6,34 kB [renderizado]
fragmento {25} 25.604287facfdf4d4ef67c.js () 5,34 kB [renderizado]
fragmento {26} 26.7da604b902f6832785fa.js () 38 kB [renderizado]
fragmento {27} 27.bdbbe5cfd351f05fb927.js () 44,5 kB [renderizado]
fragmento {28} 28.8d1645bad2f255229883.js () 6,36 kB [renderizado]
fragmento {29} 29.cae28ed727cef99550da.js () 18,2 kB [renderizado]
fragmento {30} 30.0757b5c5e76726394c96.js () 36,1 kB [renderizado]
fragmento {31} 31.f70fcde5f461f52b298f.js () 24,6 kB [renderizado]
fragmento {32} 32.f6a13d5d31d0811486c1.js () 5,32 kB [renderizado]
fragmento {33} 33.2f77b41e9e23b60d7a4c.js () 5,34 kB [renderizado]
fragmento {34} 34.75833ca150c5c8fdd6bd.js () 5,32 kB [renderizado]
fragmento {35} 35.c57bcf3e34e617dfabc6.js () 6,35 kB [renderizado]
fragmento {36} 36.5fa2d920b12f46a07172.js () 6,35 kB [renderizado]
fragmento {37} 37.a394ec89e4d0bf0d72a6.js () 6,36 kB [renderizado]
fragmento {38} 38.b34cc886a6eaa8be42a7.js () 5,37 kB [renderizado]
fragmento {39} 39.ffa574e6aed984aef474.js () 18 kB [renderizado]
fragmento {40} 40.30389c2e462dcd3da05f.js () 6,36 kB [renderizado]
fragmento {41} 41.8e53571d710cc118d3a7.js () 6,35 kB [renderizado]
fragmento {42} 42.1489d4775a8537d8cf61.js () 23 kB [renderizado]
fragmento {43} 43.d986a7e4817dc6559e1c.js () 30,8 kB [renderizado]
fragmento {44} 44.416ca46085d6452e2aae.js () 56,9 kB [renderizado]
fragmento {45} 45.807652b30c9ae86f81df.js () 48,8 kB [renderizado]
fragmento {46} 46.0b5ed5eb48ede6e2a472.js () 59,3 kB [renderizado]
fragmento {47} 47.23e8ca78a06e5de3029b.js () 51,2 kB [renderizado]
fragmento {48} 48.61a69980e6f487c0562c.js () 20,1 kB [renderizado]
fragmento {49} 49.b10ef4d1f7cad8e72cd1.js () 20,8 kB [renderizado]
fragmento {50} 50.9ad9e94f088ad56d6dd8.js () 23,6 kB [renderizado]
fragmento {51} 51.121732df2f2a4fcee042.js () 5,32 kB [renderizado]
fragmento {52} 52.d288a7457b03303af53c.js () 5,3 kB [renderizado]
fragmento {53} 53.a26d29e5795cb20db1c3.js () 36,1 kB [renderizado]
fragmento {54} 54.985c05de0e4736723d6e.js () 5,33 kB [renderizado]
fragmento {55} 55.577c2d061a42d919bbce.js () 6,67 kB [renderizado]
fragmento {56} 56.46d02993596d7be5fcc6.js () 42,5 kB [renderizado]
fragmento {57} 57.f182f866ab2ff39159a8.js () 58,9 kB [renderizado]
fragmento {58} 58.aac5f7b34340b2766b37.js () 63,3 kB [renderizado]
fragmento {59} 59.c6d03497f0a9fc3e2920.js () 5,3 kB [renderizado]
fragmento {scripts} scripts.df23d47c2e627c65cf17.js (scripts) 262 kB [entrada] [renderizado]

Angular 8. El mismo problema

Correr con node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot no ayuda

reducir --max-old-space-size=8192 , tuve que usar --max-old-space-size=4096 o menos: 2048, 1024... dependiendo del host

@bleuscyther Realmente solo cualquier uso para proyectos pequeños, perjudicará seriamente los proyectos grandes. Aún así, si tiene un proyecto pequeño, este es el escenario para usted.

@filipesilva Este parece ser un problema que entendiste bien. ¿Ha vuelto el problema? ¿Debería reabrirse esto?

Estoy usando WSL Ubuntu 18.04, probé todo lo que otros comentaron en este hilo y no puedo construir mi proyecto Angular 7.
Eventualmente me di por vencido y ahora estoy usando PowerShell para construirlo...

Esto me ayuda a resolver el problema en t2.micro, tiempo máximo de 2 minutos

crear intercambio

sudo /bin/dd if=/dev/cero of=/var/swap.1 bs=1M cuenta=3024
sudo /sbin/mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo /sbin/swapon /var/swap.1

Si necesita más o menos de 3024, cámbielo por algo que desee.

Para habilitarlo de forma predeterminada después de reiniciar, agregue esta línea a /etc/fstab:

/var/swap.1 intercambio intercambio valores predeterminados 0 0

Después de hacer todo esto, ejecute el siguiente comando

ng build --prod --build-optimizador=falso

Este problema se ha bloqueado automáticamente debido a la inactividad.
Presente un nuevo problema si encuentra un problema similar o relacionado.

Obtenga más información sobre nuestra política de bloqueo automático de conversaciones .

_{_Esta acción ha sido realizada automáticamente por un bot._}