logger_bots — Librería de logs vía API

Objetivos

• Publicar logs por HTTP (POST) hacia una API interna.
• Mostrar los logs localmente en consola con colores y sello de tiempo.
• Entregar build dual (ESM y CJS) con tipos (.d.ts).

Estructura del proyecto

logger_bots/
├── src/
│   ├── api/
│   │   └── apiLogs.ts         # Envío de logs a API (HTTP fetch)
│   ├── console/
│   │   └── console_logs.ts    # Impresión en consola con formato y colores
│   ├── utils/
│   │   └── format.ts          # Helper para formatear fechas
│   ├── index.ts               # API pública de la librería
├── scripts/
│   └── run-dist.js            # Ejemplo para probar el build compilado (ESM)
├── dist/                      # Salida de build (ESM y CJS + tipos)
├── tsconfig.json              # Configuración de TypeScript
├── tsup.config.ts             # Configuración de build (tsup)
└── package.json               # Metadatos, scripts y exports

Uso rápido

Importación en proyecto consumidor

• ESM (Node con type: "module" o bundlers modernos):

import { loggerBots, GestionBot } from "logger_bots";

await loggerBots("BotA", "info", "Proceso finalizado", "Numero de identificacion");
await GestionBot("BotA", "warn", "Reintento por timeout", "Numero de identificacion");

• CommonJS:

const { loggerBots, GestionBot } = require("logger_bots");

(async () => {
  await loggerBots("BotA", "error", "Fallo de conexión", "Numero de identificacion");
  await GestionBot("BotA", "warning", "Latencia elevada", "Numero de identificacion");
})();

Importación local para probar el build (dist)

• ESM desde dist (sin publicar):

import { loggerBots } from "../dist/index.js";
await loggerBots("BotTest", "info", "Prueba desde dist", "NumId");

• CJS desde dist:

const { loggerBots } = require("../dist/index.cjs");
(async () => {
  await loggerBots("BotTest", "info", "Prueba CJS dist", "NumId");
})();

Desarrollo con TypeScript (ts-node ESM)

Si ejecutas archivos .ts directamente con ts-node en ESM, usa la extensión .ts en imports relativos:

// src/test.ts
import { loggerBots } from "./index.ts";
await loggerBots("BotDev", "info", "Prueba dev", "USR-001");

API pública

La librería expone dos funciones desde src/index.ts:

• async loggerBots(bot: string, type: string, message: string, responsible: string): Promise<void>

  • Envía un POST a https://api.gnp/bots/logger_bots con el payload { date, message, bot, type, responsible }.
  • Si ocurre un error de red, registra un error en consola y continúa (no lanza la excepción al consumidor).
  • Siempre imprime el log en consola con colores y fecha.

• async GestionBot(nombre_bot: string, tipo_log: string, mensaje: string, id_responsable: string): Promise<void>

  • Wrapper que delega internamente en loggerBots(nombre_bot, tipo_log, mensaje, id_responsable).
  • Útil si prefieres nombres en español o mantener compatibilidad con código existente.

Parámetros y valores válidos

• bot | nombre_bot: nombre del bot o proceso que genera el log.
• type | tipo_log: tipo de log. Valores aceptados:
  • "info" (o cualquier otro distinto de error/warn/warning) → verde.
  • "warn" o "warning" → amarillo.
  • "error" → rojo y se usa console.error.
• message | mensaje: descripción corta del evento.
• responsible | id_responsable: identificador del responsable (usuario, proceso). Puede ser string como "1548845321" usado para rastrear quién es el propietario del bot.

Comportamiento de consola

console_logs.ts formatea los logs con:

• Fecha en formato DD/MM/YYYY HH:mm:ss.
• Prefijo con nombre del bot y tipo de log (INFO, WARN, ERROR) coloreado.
• Usa console.log / console.warn / console.error según el tipo.

Endpoint y configuración

• Endpoint actual: https://api.gnp/bots/logger_bots (hard-coded).
• Payload: { date: string (ISO), message: string, bot: string, type: string }.
• Recomendación: parametrizar el base URL vía variable de entorno o proveedor externo (no implementado aún). Un patrón futuro podría ser:
  • PG_LOGGER_BASE_URL=http://mi-api:8787
  • Expone un setter: setLoggerBaseUrl(url: string) para cambiar el destino en runtime.

Instalación

npm i logger_bots

Si estás probando localmente sin publicar:

npm pack
# Instalar el .tgz en un proyecto consumidor
npm i ../REPOSITORIO AUTOMATIZACIONES/LIBRERIAS/logger_bots/logger_bots-1.0.0.tgz

Scripts

• build: compila la librería con tsup a ESM y CJS, y genera tipos.
• dev: lanza tsup --watch para builds incrementales.
• test: ejecuta el src/test.ts con ts-node en modo ESM.

Ejemplos:

npm run build
npm run dev
npm run test

Para probar el dist (ESM):

node ./scripts/run-dist.js

Build y formatos

• Herramienta: tsup.
• Configuración (tsup.config.ts):
  • entry: ["src/index.ts"] (solo la API pública)
  • format: ["esm", "cjs"]
  • dts: true (emite declaraciones de tipos)
  • external: ["sequelize", "pg", "pg-hstore"] (marcados externos; actualmente la librería no los usa)

Salidas esperadas en dist/

• ESM: index.js, tipos: index.d.ts
• CJS: index.cjs, tipos: index.d.cts

Exports en package.json

{
  "main": "dist/index.cjs",
  "types": "dist/index.d.ts",
  "type": "module",
  "module": "dist/index.mjs", // Campo informativo; la salida real ESM es index.js
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.js",
      "require": "./dist/index.cjs"
    }
  }
}

TypeScript y configuración

tsconfig.json:

• module: "ESNext" y target: "ES2020".
• moduleResolution: "node" para evitar exigir extensiones en import relativos durante el desarrollo.
• lib: ["ES2020", "DOM"] para que fetch esté tipado.
• types: ["node"].

Requisito de runtime:

• Node 18+ recomendado (incluye fetch nativo). En Node < 18, instala undici y usa import { fetch } from 'undici'.

Pruebas de la librería

Desarrollo (sin compilar)

Usa ts-node en modo ESM:

npx ts-node-esm src/test.ts

src/test.ts importa desde ./index y ejecuta algunos loggerBots de ejemplo.

Contra el build (dist)

Ejecuta el script de ejemplo ESM:

node ./scripts/run-dist.js

Para CJS, crea scripts/run-dist.cjs con:

const { loggerBots } = require("../dist/index.cjs");
(async () => {
  await loggerBots("BotTest", "info", "Prueba desde dist (CJS)");
})();

Desde un proyecto consumidor (realista)

1. Empaqueta: npm pack.
2. Instala el .tgz en el consumidor: npm i <ruta>/logger_bots-1.0.0.tgz.
3. Importa y usa:

import { loggerBots } from "logger_bots";
await loggerBots("ConsumerBot", "info", "Test desde consumidor");

Errores frecuentes y soluciones

• Cannot use import statement outside a module

  • Causa: ejecutar ESM como CJS.
  • Solución: usa node --loader ts-node/esm o npx ts-node-esm para .ts en ESM; o ejecuta el build ESM (dist/index.js) con type: "module".

• Unknown file extension ".ts"

  • Causa: Node intenta cargar .ts sin loader.
  • Solución: npx ts-node-esm src/test.ts o node --loader ts-node/esm ./src/test.ts.

• MODULE_NOT_FOUND: dist/test.js

  • Causa: el build no incluye src/test.ts.
  • Solución: ejecuta el test directamente con ts-node o usa scripts/run-dist.js para probar dist.

• DTS Build error con NodeNext

  • Causa: mezclar moduleResolution: "NodeNext" obliga extensiones explícitas en import relativos (./api/apiLogs.js) y puede generar conflictos.
  • Solución: usa moduleResolution: "node" para desarrollo de librería simple, o añade extensiones en todos los import si decides NodeNext.

• Paths en Git Bash (\)

  • Causa: el backslash escapa caracteres (srctest.ts, .scriptsrun-dist.js).
  • Solución: usa rutas con / en Git Bash (./src/test.ts, ./scripts/run-dist.js) o ejecuta en PowerShell/CMD.

• fetch no definido

  • Causa: Node < 18.
  • Solución: instalar undici: npm i undici y importar fetch desde ahí.

Escenarios de éxito

• Log enviado correctamente a la API (200/2xx):

  • El servidor recibe { date, message, bot, type }.
  • La consola local muestra el log con el formato esperado.

• Error de red/API:

  • Se imprime un log ERROR en consola con el detalle del fallo.
  • No se lanza excepción hacia el consumidor (la función loggerBots no la propaga). Si prefieres propagar el error, ajusta el catch.

Variables de Entorno por el (Consumidor)

La librería NO carga dotenv. El proyecto consumidor debe gestionar sus secretos y cargar el entorno (por ejemplo, con dotenv) y la librería leerá process.env.

El usuario que consuma la librería debe definir las siguientes variables de entorno usando dotenv en su proyecto:

• En el .env se deben definir las siguientes variables de entorno:
  • Url del api que consume la libreria: URL_API_LOGGER (debera definirse la url del api)
  • Token de autenticación debe ir con el siguiente nombre: TOKEN_LOGGER (debera definirse el token de autenticación)
  • La librería usa Authorization: Bearer ${process.env.TOKEN_LOGGER} lo que hace que se tome el token de autenticación definido en el .env del consumidor
• en dado caso de fallos se debera revisar lo siguiente:
  • La existencia del insumo .env
  • La existencia de las variables dentro del .env
  • La correcta definición de las variables en el .env (sin espacios, etc.)
  • La correcta asignación de los valores a las variables en el .env
• Recomendación: no commitees el .env (usa .gitignore) y no imprimas el token en logs.

Consumidor ESM (con dotenv)

// Definir la liberia dotenv
import dotenv from "dotenv";
import { loggerBots, GestionBot } from "logger_bots";

// inyectar el dotenv en el proyecto
dotenv.config();


await loggerBots("BotA", "info", "Proceso OK", "USR-123");
await GestionBot("BotA", "warn", "Reintento por timeout", "USR-123");

Ejemplo de .env del consumidor:

URL_API_LOGGER=https://api.logger_bots.example.com
TOKEN_LOGGER=1234567890abcdef1234567890abcdef