Despidiéndome de Console.log

#node #javascript #spanish #beginners

El dilema

Llevaba tiempo con la idea de replantearme el uso de console.log() en mis proyectos de estudio. Las evidencias provenían de cuatro actores clave: ESLint, con sus persistentes advertencias, indicándome que no era la mejor práctica; mi propia sospecha de que debía existir una alternativa más eficiente; y, por último, la insistencia de mi profesor de entregar las prácticas sin la presencia de console.log(), emulando así un entorno de producción más estricto.

Demasiado bueno para ser cierto

Desde el principio, me limité a utilizar dos enfoques. El más rápido: /* eslint-disable no-console */ al inicio del documento. Como alternativa, prescindir completamente de su uso, mejorando así la estructura y legibilidad del código.

No nos engañemos, evitar el uso de console.log() bajo la excusa de mejorar mis habilidades de desarrollo ha sido una idea que ha alimentado mi ego durante este año y medio. Aunque seguía intuyendo que debía haber algo más. Claro, el uso de debugger estaba ahí, pero console.log() seguía siendo más simple y rápido de implementar. No me convencía completamente como alternativa directa.

History Time

Los eventos de desarrollo suelen ser oportunidades mágicas de aprendizaje. Un día, durante el OpenSourceJam en Alicante, esta revelación llegó de manera inesperada.

Evento: OpenSourceJam Alicante.
Fecha: 18 de Noviembre de 2023.

Junto a otras dos personas, contribuíamos al código abierto. Mi tarea consistía en desarrollar un pequeño crawler con Express.js y Puppeter para obtener datos de eventos Tech. Del otro lado, Noe y Cesar trabajaban en el frontend con Next.js.

La sorpresa llegó cuando Cesar, con una sonrisa pícara, anticipando que me iba a gustar lo que tenía que decirme, mencionó algo sobre mi Pull Request en GitHub. En ese momento, me encontraba abrumado y luchaba por comprender lo que estaba diciendo.

Mi curiosidad se disparó cuando, tras actualizar la rama y ejecutar el proyecto, vi por consola:

Server running on port 3000

En verde y negrita, pero sin rastro de console.log(). En ese momento, mis sospechas se confirmaron: existía una alternativa viable y eficiente. Continuamos con el proyecto, y la lección quedó grabada.

Después de un tiempo

Ha pasado un tiempo desde ese episodio y fue hoy, durante la revisión del Backend de mi proyecto final de 2ºDAW, donde tuve el flashback. Tenía mi console.log('Server running on port 3000'); junto a la cláusula /* eslint-disable no-console */ y no pude aguantar más. Me dirigí al repositorio del evento y descubrí algo muy sencillo, rápido y que implementaré como mínimo a partir de ahora.

El código

Nos encontramos en /src/utils/logger.js y podemos encontrar estas simpáticas líneas:

import chalk from "chalk";

const { log } = console;

export default {
  info: (...args) => {
    log(chalk.blue(...args));
  },
  error: (...args) => {
    log(chalk.red(...args));
  },
  warning: (...args) => {
    log(chalk.yellow(...args));
  },
  success: (...args) => {
    log(chalk.green(...args));
  },
};

¡Había deconstruido console.log() y creado su propia versión! 👀 La librería chalk.js añade colores y decoraciones a la terminal.

Terminal string styling done right

y un ejemplo de uso del mismo proyecto:

logger.info(`Saving ${records.length} events`);

El método ofrece mensajes más amigables con el desarrollador y ESLint no se queja más.

Aún así, mi curiosidad me ha empujado a encontrar formas más elegantes y prácticas como Winston y el log4js; este último me sonaba porque saltó a la palestra hace tiempo por fallas de seguridad, pero no profundicé más al respecto.

Conclusión

Despedirme de console.log() no va solo de seguir ciertas convenciones o reglas, sino de elevar la calidad y la estética del código. Continuaré con otra entrada explicando cómo voy a añadir Winston al proyecto.

¿Tienes alguna anécdota sobre la transición de console.log() a otras alternativas? ¡Me encantaría escuchar tus historias!