ANGULAR2: ese gran desconocido, Webpack

Angular-CLI

Angular-CLI es una herramienta que nos la ofrece el propio equipo de Angular y que facilita mucho el proceso de inicio de cualquier aplicación basada en la tecnología, además de generar automáticamente una gran cantidad de herramientas ya configuradas para realizar la mayoría de las operaciones necesarias comprendidas en el ciclo de vida de un proyecto, como hacer builds, lanzar el proyecto en local y ejecución de test, tanto unitarios como de integración.

Angular-CLI es una herramienta NodeJS, es decir, que necesitaremos contar con NodeJS para instalarla (recomendable instalarla de forma global en nuestro PC). Una vez instalada, dispondremos del comando "ng" a partir del cual podremos lanzar cualquiera de las acciones. Sin embargo, utilizando npm ("Node Package Manager") que es el gestor de paquetes de NodeJS, podremos gestionar todos esos mismos comandos mediante scripts de npm, abstrayéndonos de la implementación concreta del comando interno (esto veremos más adelante que es bastante útil).

Los scripts de npm son como subcomandos que npm acepta para automatizar diferentes tareas. Éstos se definen en el archivo "package.json", en la sección "scripts". Generalmente, temdremos los siguientes definidos por defecto:

Los script de npm son herramientas bastante potentes y nos permiten hacer multitud de tareas, incluso encadenando varias de ellas, cuya complejidad escapa al alcance del artículo . Solamente mencionar como cada uno de los script en el fondo, de lo que se encarga es de lanzar un comando de nuestro Angular-CLI.

Eyección del proyecto: uso de Webpack

Angular-cli nos provee una funcionalidad que es eyectar el proyecto. Explicar qué hace este comando y para qué nos sirve es el objetivo principal del artículo. Pero primero veamos cómo tenemos que hacerlo, se realiza en dos sencillos pasos:

1. Ejecutamos el comando ‘ng eject’ mediante el cual Angular-cli nos genera un nuevo fichero en la raíz del proyecto, es este: webpack.config.js.
2. A continuación ejecutamos el comando ‘npm install’ para que npm nos instale todas dependencias que el comando eject nos ha añadido en nuestro package.json y que necesita webpack para funcionar.

Tras realizar estos sencillos pasos, tendremos nuestro proyecto eyectado. En teoría, en este punto nuestro proyecto debería funcionar de la misma manera que antes, sólo lanzando nuestros correspondientes comandos de build o start desde npm el propio gestor se encarga de lanzar los comandos directos de Webpack que realizan las tareas correspondientes. Pero, ¿qué ha supuesto eyectar el proyecto? ¿Qué cambios ha generado a nivel de ficheros? Son los tres siguientes:

1. El primer cambio y más evidente es la generación del fichero de configuración de Webpack: webpack.config.js
2. El segundo es que nos ha añadido una nueva propiedad al fichero de configuración de Angular CLI, nos ha escrito un: "ejected": true en el fichero angular-cli.json.
3. Por último podemos ver como se ha modificado el package.json, sobre todo añadiendo las dependencias de wekbpack, y lo más importante modificando nuestra sección de scripts con los comandos nuevos, quedando algo así:

Como se puede observar, a través de los scripts ahora ya no utilizamos Angular CLI, y directamente estamos llamando a Webpack para el build y el serve. Además, utilizamos directamente tanto Karma como Protactor para la ejecución de los test, referenciado nuestros ficheros correspondientes de configuración para cada herramienta, los cuales ya se usaban desde Angular CLI pero ahora los tenemos directamente referenciados en el comando. A partir de este momento, ya no nos será posible volver a utilizar ninguno de los comandos del Angular CLI, pues la consola nos mostrará un error similar a este:

El fichero de configuración de Webpack

Una de las grandes ventajas que tiene eyectar un proyecto, respecto a la estrategia de continuar utilizando Angular CLI, que si bien es mucho más sencillo y nos abstrae de muchas configuraciones engorrosas, no da ni la flexibilidad ni la potencia que se tiene disponible al utilizar Webpack directamente configurándolo desde su correspondiente fichero.

El proceso de ejecución genera un fichero webpack.config.js bastante genérico, pero en él se puede ver varias partes más o menos diferenciadas:

Nos vamos a centrar principalmente en el apartado de plugins, pues existen una gran cantidad de ellos disponibles para su uso, y son éstos lo que dan todas las posibilidades para configurar los parámetros de nuestro build.

Hay plugins de todo tipo y pueden realizar labores de cualquier índole: definir el grado de minificación y compresión de nuestro código para reducir el tamaño de nuestros ficheros generados, copia de assets y recursos, tanto anteriores como posteriores al proceso de build y la sustitución de variable en ficheros según expresiones regulares, para, por ejemplo, definir diferentes urls dinámicamente según el entorno en el estemos desplegando.

Así, existen muchos y muy variados plugins que pueden hacer casi cualquier aspecto que un proceso de build pueda requerir, y es aquí donde entra la principal ventaja que tiene eyectar un proyecto. En la flexibilidad y potencia que permite el poder controlar casi cualquier aspecto nosotros mismos, sin más que utilizar un plugin y definir, quizá, una pocas líneas de lógica en el fichero.

Se pueden encontrar muchos ejemplos en la red de cómo utilizar cada plugin, y cuáles son sus principales funciones, así como de cuál de ellos es el que se necesita para resolver cada uno de los determinados problemas a los que todos nos hemos enfrentado alguna vez a la hora de realizar el build de nuestro proyecto.

No sólo es posible utilizar plugins oficiales, sino que existe la posibilidad de crear plugins a medida, lo cual aumenta el número de posibilidades pues la comunidad alrededor de Webpack tiene bastantes plugins desarrollados, sin embargo esta posibilidad puede conllevar el riesgo de que dichos plugins no estén correctamente desarrollados ni suficientemente probados y nos generen más problemas que soluciones. Además, podéis encontrar una lista de plugins oficiales y sus características en la documentación oficial de Webpack.

Así mismo, la eyección nos genera un fichero de configuración en JavaScript por defecto, pero podemos cambiar el lenguaje en el que queremos codificar este fichero con unos sencillos pasos. Todo esto lo podemos encontrar en la documentación oficial de Webpack en su página web.

Obviamente eyectar un proyecto puede no ser la mejor opción para todos, ya que se requieren ciertos conocimientos técnicos para poder modificar el fichero de configuración así como tiempo para encontrar lo plugins necesarios para que nuestro build funcione correctamente, tiempo que nos ahorramos si Angular CLI lo puede hacer por nosotros y no tenemos ningún requerimiento extra que nos fuerce a eyectar.

Por ello vamos a contar cuál es el proceso de revertir esta eyección, que si bien no es automático, sí se hace de una manera muy sencilla.

Revertir la eyección del proyecto

Si para eyectar un proyecto sólo se neceitan un par de pasos, revertir este proceso es todavía más sencillo. Al eyectarlo, uno de los cambios que se producían en nuestro código era que se añadía la propiedad ejected en el fichero angular-cli.json, para revertir el proceso sólo tenemos que ponerla a false, o borrarla directamente.

No se requiere ningún otro cambio adicional, y a partir de ese momento podremos lanzar de nuevo cualquier comando de Angular CLI, pues el comprueba ese flag para saber si el proyecto está eyectado o no. No hay ningún otro cambio necesario en los ficheros, pero es muy recomendable limpiar los cambios de fichero package.json, tanto las dependencias que no se usan (y hacer de nuevo un npm install para que dejar dependencias no usadas en la carpeta node_modules) como revertir los cambios en los script, para que al lanzar nuestras tareas con npm, éste por debajo, se encargue de utilizar de nuevo los comandos de Angular-CLI. 

El fichero webpack.config.js podéis mantenerlo si queréis, no se va a usar para nada, pero puede ser interesante en un futuro, en caso de que decidáis darle otra oportunidad a la eyección del proyecto.

Ventajas de cada herramienta

A modo de resumen terminaremos con una pequeña lista desgranando las principales ventajas que nos brindan ambas herramientas.

Ventajas de Angular-CLI

•  Más sencillo: Angular-CLI se encarga de gestionar Webpack internamente, haciéndolo de manera transparente para el desarrollador que no necesita preocuparse de ninguna configuración adicional
• Casi Automático: no requiere ningún tipo de gestión ni adaptación, creamos el proyecto o incorporamos Angular-Cli a uno ya existente y nos da todas las herramientas para desarrollar y hacer nuestros build de manera automática sin perder ni un ápice de tiempo.
• No requiere conocimientos técnicos específicos, ni leer documentación extra sobre herramientas adicionales que no sean las que necesitemos para el propio desarrollo de la funcionalidad de nuestros proyectos, que ya bastante tenemos con ellas.
•  Menor riesgo, estándar: obviamente tener una herramienta automática y estándar nos elimina un riesgo adicional al tener que mantener otra herramienta adicional mucho más compleja.
• Soporte: al ser una herramienta “oficial” (entrecomillado ya que en ningún caso Angular nos obliga a usarlo, aunque es recomendado) contamos con todo el soporte que ello conlleva en cuanto a solución de problemas y bugs.
• También es configurable: Angular-CLI también dispone de su fichero de configuración, es cierto que no es demasiado flexible y no permite demasiada variación, pero es cierto que nos permite hacer cosas sencillas y que quizá nos sean suficientes. A ello podemos sumar que también permite la adición de parámetros a los comandos que lanzamos, lo cual al menos nos permite cierto juego sin complicarnos en exceso.
• Documentación: tiene una wiki con la documentación oficial actualizada para su consulta, lo suficientemente descriptiva y desarrollada para que resulte útil, donde además explica cómo es posible abrir issues y bugs a los desarrolladores para su estudio y posible solución en futuras versiones.

Ventajas de Webpack

• Más potente y flexible, Webpack nos permite realizar muchísimas más tareas que el estándar build Angular-cli no se atreve ni a soñar.
• Configurable a tu gusto: no solo nos permite realizar más tareas, sino que podemos realizarlas de la manera que más nos convenga. Para cada requerimiento necesario podemos tenemos varias maneras de alcanzar al objetivo deseado.
• Facilita la configuración por entorno (local, dev, preporducción, producción): debido a la flexibiliad y configurabilidad brindada por Webpack, podemos mantener más fácilmente configuraciones dedicadas a cada entorno, que serán cambiadas en tiempo de generación de build.
• Estándar: Webpack también es estándar, de hecho Angular-CLI lo está utilizando por debajo sin que seamos completamente consciente de ello. Es una herramienta utilizada en cualquier proyecto de Angular.
• Comunidad: es también algo cuasiofical, no llega a los extremos de Angular-CLI, pero tiene una empresa detrás, lo que nos asegura cierto soporte. Pero quizás es más importante el soporte que nos brinda la comunidad, ya que por su flexibilidad permite que cualquiera pueda desarrollar sobre su base, pudiendo encontrar, por ejemplo, multitud de plugins a medida desarrollados por developer de todo el mundo.
• Parámetros: obviamente si lo permite Angular-CLI lo permite Webpack, sólo que aquí las posibilidades aumentan exponencialmente al poder acceder a ellos desde nuestro fichero de configuración, donde podemos involucrarlos en la lógica y complicarnos hasta límites insospechados.
• Documentación: Webpack contiene una extensa documentación oficial, donde podemos ver todas las posibilidades que nos ofrece desarrolladas y con ejemplos prácticos, con el fin de no perder al desarrollador entre toda la maraña de opciones que ofrece. Aunque a decir verdad no es tan fácil de seguir, si bien sí está bien estructurada y los ejemplos y explicaciones aporta bastante claridad. 

Ahora que ya tenemos claro qué es lo que nos ofrece cada una de las herramientas, es turno de los desarrolladores y líderes técnicos de cada proyecto decidir qué les conviene más utilizar, dependiendo de los requisitos que tengamos, pero siempre teniendo en cuenta que cualquier decisión inicial que tomemos puede ser cambiada a posteriori sin demasiado trabajo adicional, según veamos en cada momento las necesidades concretas a las que nos enfrentamos.

En próximos artículos nos centraremos en mayor detalle en cómo poner solución a determinados problemas técnicos concretos utilizando los plugins oficiales de Webpack y desarrollando nuestra propia lógica en el fichero de configuración.

José Antonio Blanes

José Antonio es Jefe de Equipo en DxD de Deloitte, formando parte del área de movilidad dentro de la competencia Java. Profesional con más de siete años de experiencia, todos ellos en la firma, como desarrollador web, primero de aplicaciones basadas en el paradigma J2EE, y en la actualidad más centrado en el desarrollo web frontend basado en Angular, así como en la implementación de aplicaciones híbridas para dispositivos móviles, con más de dos años de experiencia en este tipo de desarrollos. Actualmente combina sus labores como desarrollador con la gestión de equipos y tareas dentro de la metodologías ágiles, formando parte del Development Team.