Webpack se usa muy comúnmente en aplicaciones web de las denominadas SPA (Single Page Application), pero puedes beneficiarte de esta herramienta desde cualquier otro tipo de sitio web. En este artículo te vamos a explicar las claves y procedimiento para utilizar Webpack en sitios que deban servirse a través de otros servidores como Apache, Nginx, etc.

Como sabes, Webpack te permite generar los archivos para llevar a producción la parte frontend de las aplicaciones. Pero entonces, si el uso de un servidor web del estilo de Apache viene marcado por tus tecnologías backend, ¿Por qué necesitamos un procedimiento específico para trabajar con Webpack, que se dedicada al frontend?

Dependiendo del stack de tecnologías frontend que estés usando, puede que sea necesaria la transformación de ciertos códigos de frameworks y librerías como React, Polymer o preprocesadores como Sass. Por tanto, puede que haya partes del tu código frontend que no puedas ejecutar desde el navegador directamente, si es que no se procesan antes por alguna herramienta del estilo de Webpack. Cuando es necesaria la transformación del código frontend Webpack permite un flujo de desarrollo más depurado. Gracias a su servidor de desarrollo somos capaces de obtener de una manera sencilla la habilidad del live-reload, o hot-reload, produciendo sobre la marcha los archivos necesarios y refrescando automáticamente el navegador para mostrar los cambios.

El asunto es que, si está haciendo un sitio web tradicional y trabajas con algún lenguaje de servidor, como PHP, .NET, Python, etc. Seguramente tengas que usar algún servidor web como Apache o IIS que procese esos lenguajes antes de enviar el código HTML al cliente. Por ese motivo, no podemos valernos simplemente del servidor de desarrollo que ofrece Webpack y por tanto no seremos capaces de aprovechar todas las ventajas de su flujo de trabajo. En resumen, cada vez que se actualice alguna parte de nuestro frontend (tu código Javascript, TypeScript o el código Sass u otros preprocesadores...) tendremos que lanzar a mano el proceso de producción de los archivos y refrescar también la página, evitando de cualquier manera disponible la entrada en funcionamiento de la caché del navegador.

La solución para poder combinar ambos mundos (un desarrollo apurado de tu frontend + el lenguaje de preferencia en el backend), es sencilla y la puedes poner en marcha en pocos instantes. Te explicamos los pasos a continuación. Obviamente, para poder seguir este procedimiento, tendrás que tener algún conocimiento previo de Webpack, por lo que te recomendamos la lectura antes del Manual de Webpack.

Instalar webpack-dev-server

Igual que si estuvieras usando Webpack para una aplicación SPA o una PWA, tendrás que instalar el paquete de Node webpack-dev-server. En este caso, el servidor de Webpack se encargará simplemente de servir los bundles de tu aplicación, es decir, el Javascript y el CSS. Mientras que el servidor Apache, Ngnix, IIS (o el que sea) se encargará de servir el código HTML.

npm install -D webpack-dev-server

Igual que siempre, podremos poner en marcha el servidor de desarrollo mediante un script npm, como hemos aprendido anteriormente en el Manual de Webpack.

"scripts": {
    "start": "webpack-dev-server --mode development"
}

Configurar Webpack para definir la ruta donde estarán accesibles los bundles

Ahora vamos a ver una configuración del archivo webpack.config.js en la que podemos definir una ruta y un puerto para el servidor donde va a estar disponible el código generado por Webpack.

module.exports = {
  devServer: {
    port: 9999
  },
  output: {
    publicPath: 'http://localhost:9999/bundles/'
  },
  devtool: 'inline-source-map'
}

Esta configuración podrá cambiar según tus preferencias y necesidades de producción de los bundles. Es solo una muestra para poder guiarte.

En ella encontramos varias cosas destacables:

• El puerto del servidor de desarrollo, que lo he colocado a 9999. Usa el que mejor te venga. Yo uso ese puerto porque seguramente estará libre, ya que no corresponde con otros puertos habituales de servidores web o servidores de desarrollo.
• El output es el lugar donde estarán públicos tus bundles. Lo puedes usar para saber de manera sencilla donde estará tu código producido para desarrollo. Luego vamos a usar esa ruta para poder acceder al bundle que se ha generado.
• La configuración devtool: 'inline-source-map' me permite disponer de las ventajas de los sourcemaps, así cualquier error en la consola Javascript informará del lugar de mi propio código donde se ha encontrado el problema, y no de la posición del fallo en el código del bundle.

Enganchar los scripts del bundle en la etapa de desarrollo

En tu código backend, colocarás la ruta donde está el bundle del servidor de desarrollo de webpack. Tal como lo hemos configurado en el paso anterior, la etiqueta SCRIPT que deberíamos colocar en el HTML sería como esta:

<script src="http://localhost:9999/bundles/main.js"></script>

Fíjate que hemos usado la misma ruta del "publicPath" en la configuración output de Webpack. Seguida del bundle Javascript que tiene su nombre predeterminado (main.js).

Enganchar los scripts del bundle para producción

Pero claro, esta etiqueta SCRIPT anterior nos lleva a un servidor de desarrollo, que tenemos arrancado en nuestro ordenador. Ningún usuario tendrá esa ruta activa. Para producción tendremos que colocar las rutas de los bundles producidos.

Esta parte la tendrás que hacer de la manera como hemos explicado ya en el Manual de Webpack. En mi caso uso un archivo de configuración de Webpack específico para cuando voy a llevar a producción, donde el output está dirigido a una carpeta de Apache. En resumen, para producción, la etiqueta SCRIPT irá dirigida a una URL dentro del directorio de publicación del servidor web.

<script src="js/main.js"></script>

Usar variables de entorno para mostrar una u otra etiqueta SCRIPT

Para no tener que ir cambiando la etiqueta SCRIPT todo el tiempo (colocando la válida cuando estoy desarrollando y la válida cuando estoy publicando el sitio web), facilitando el flujo de desarrollo y evitando el problema de olvidarme de cambiar la etiqueta SCRIPT al llevar a producción, lo ideal es crearse un sistema de variables de entorno.

Por ejemplo, podríamos tener una variable de entorno que nos diga si estamos ejecutando el sitio web en local (desarrollo) o en remoto (producción). El código simplificado al máximo en PHP podría ser algo como esto:

<?php
if($estoyEnProduccion) {
  echo '<script src="js/main.js"></script>';
} else {
  echo '<script src="http://localhost:9999/bundles/main.js"></script>';
}
?>

Ya, dependiendo de la gestión de tus variables de entorno y de tu sistema de templates, podrás tener variantes de este código bien diferentes. Ni que decir tiene que, si estás trabajando con otro lenguaje o plataforma de desarrollo, como Python, ASP.NET, etc., el código para producir este mismo efecto será completamente distinto, pero en esencia se compondrá de una expresión condicional que permita colocar una u otra etiqueta de SCRIPT dependiendo de si nos encontramos en el servidor de desarrollo o en el de producción.

Conclusión

Con lo que hemos conocido en este artículo del Manual de Webpack podrás sacarle todo el provecho a esta herramienta en el desarrollo de sitios web tradicionales, ayudando mucho a mejorar tu flujo y creando una experiencia de desarrollo muy agradable y productiva, ya que nos permite disponer del live-reload, con una configuración hecha en pocos minutos.

Durante la etapa de desarrollo, Apache, o tu servidor web tradicional, se encargará de servir el HTML, mientras que todo archivo que necesites procesar con Webpack se servirá desde Webpack-dev-server. Los bundles Javascript de Webpack-dev-server ya tienen el live reload configurado de manera predeterminada.

Podrás usar estos consejos para sitios web basados en contenido, con cualquier framework como Symfony, Laravel, o basados en CMS como WordPress. Así como en cualquier otro lenguaje de backend donde estés renderizando HTML. Esperamos haberte ayudado.