Node.js detrás de mis scripts de build

Cuando alguien pregunta para qué uso Node, piensa automáticamente en un servidor con Express escuchando peticiones. En mi día a día, la mayoría de mis scripts en Node.js no sirven ninguna petición — corren una vez, hacen su trabajo, y terminan. Nadie los ve. Pero si fallan, sí que se nota.

Lo que de verdad corre en mis proyectos

En proyectos con framework (SvelteKit, Astro) esto ya viene resuelto por el propio build. Pero en clientes más pequeños, sin ese framework, sigo teniendo un puñado de scripts sueltos en Node: uno que recorre una carpeta de imágenes subidas por el cliente y las convierte a WebP antes de subirlas al servidor, otro que genera un sitemap.xml a partir de los archivos Markdown del proyecto, y uno que reviso siempre antes de un despliegue grande: comprueba que ningún enlace interno apunte a una página que ya no existe.

Ese último me ha salvado más de un despliegue vergonzoso. Antes de tenerlo automatizado, dependía de acordarme de comprobarlo a mano, y las veces que se me olvidó siempre fueron las veces que algo se había movido sin que yo me diera cuenta.

Por qué no bash

Podría hacer buena parte de esto con scripts de shell, y alguna vez lo he hecho. Pero en cuanto necesito leer un archivo, transformar datos o hacer algo mínimamente complejo con strings, prefiero quedarme en un lenguaje que ya conozco bien y con acceso al ecosistema de npm — una librería de procesado de imágenes como sharp me ahorra reinventar algo que en bash sería mucho más frágil.

Lo aburrido que es, y por qué está bien que lo sea

Ninguno de estos scripts es interesante de enseñar. No hay arquitectura elegante ni patrón de diseño digno de mención. Son funciones cortas, sin dependencias raras, que hacen una cosa cada una. Y esa es precisamente la razón por la que llevan años funcionando sin que tenga que volver a tocarlos: cuanto más aburrido y directo el código de infraestructura, menos sorpresas da cuando lo ejecutas medio dormido antes de un despliegue.