La mayoría de las afirmaciones de rendimiento en el espacio de las herramientas de JavaScript tienen la vida útil de la leche. Alguien instala unos cuantos paquetes una mañana tranquila de martes, captura la salida de la terminal y publica un gráfico de barras dramático. Para el siguiente sprint, una de las herramientas ha lanzado un parche que invalida todo el asunto. La publicación sigue indexada por los motores de búsqueda. El gráfico se sigue compartiendo. Sin embargo, los números ya te están mintiendo.

Esta es la podredumbre que infecta casi todos los benchmarks de gestores de paquetes. Son como fotografía de eventos cuando lo que necesitamos es una transmisión en vivo.

Un proyecto llamado depjs/canary trata este problema como una responsabilidad de la máquina en lugar de una tarea de un calendario de contenidos. Es un benchmark vivo que vigila npm, pnpm, Yarn y dep, y luego vuelve a ejecutar toda su suite en el momento en que cualquiera de ellos publica una nueva versión. Los resultados son públicos, continuos e inevitables. Cuando algo se rompe, el repositorio permanece en rojo hasta que se soluciona. No hay selección selectiva, no hay escondites tras una vieja publicación de blog, ni suposiciones de que el ganador del mes pasado todavía conserve la corona.

Por qué las afirmaciones de velocidad necesitan una fecha de caducidad

Los gestores de paquetes de JavaScript no se quedan quietos. El intervalo entre versiones menores puede incluir algoritmos de resolución reescritos, estrategias de hoisting alteradas o cambios en la forma en que se indexa la caché global. Un benchmark que captura npm 10.2.1 y pnpm 8.11.0 casi no te dice nada sobre cómo se comportan esas mismas herramientas dos lanzamientos después. Sin embargo, la web está llena de afirmaciones definitivas como "la herramienta X es tres veces más rápida" basadas precisamente en ese tipo de instantáneas congeladas.

Peor aún, muchas pruebas ignoran las condiciones que definen el verdadero dolor de los desarrolladores. Un gestor de paquetes puede realizar una instalación a toda velocidad en un entorno cálido y bien ensayado, y luego avanzar a paso de tortuga en un runner de CI que comienza con un disco vacío. Sin probar ambos extremos, el benchmark se convierte en un comunicado de prensa en lugar de datos de ingeniería útiles.

Cómo el canary automatiza la comparación

Cada dos horas, un trabajo consulta el registro de npm. Si aparece una nueva versión de npm, pnpm, Yarn o dep, el canary se despierta. No espera a que un humano note el changelog. Ejecuta inmediatamente una matriz de pruebas completa que enfrenta a los cuatro gestores contra cinco paquetes populares del mundo real. La selección incluye pesos pesados como React, Next.js y Vite, bases de código que los desarrolladores reales instalan todos los días. Estos no son microproyectos sintéticos diseñados para halagar a una herramienta en particular.

Este enfoque activado por lanzamientos es importante porque vincula la medición directamente al cambio. Si el benchmark solo se ejecutara con una programación nocturna, podría perderse un hotfix a mitad del día o ignorar una regresión durante horas. Al ejecutarse específicamente con las nuevas versiones, el canary hace una pregunta directa cada vez: ¿este lanzamiento ha mejorado o empeorado las cosas?

Los cuatro escenarios que ponen a prueba diferentes músculos

La matriz de pruebas se construye en torno a cuatro configuraciones distintas que se corresponden directamente con flujos de trabajo que reconocerás.

  • Caché fría, sin lockfile. Este es el clonado fresco en un portátil nuevo, o la primera instalación tras borrar node_modules. Nada está en caché. Nada está fijado. El gestor de paquetes tiene que resolver, descargar y escribir todo desde cero.
  • Caché cálida, con lockfile. Este es el camino ideal para la integración continua cuando todo sale bien. El lockfile existe localmente y la caché aún conserva los tarballs de una ejecución anterior. La herramienta debería moverse rápido porque la mayoría de las decisiones ya se han tomado.
  • Caché fría, con lockfile. Aquí el lockfile está presente, pero la caché ha sido borrada. El gestor puede omitir la resolución de dependencias, pero aún tiene que descargar cada byte a través de la red. Esto aísla la velocidad de red de la velocidad de resolución.
  • Caché cálida, sin lockfile. La caché está caliente, pero el lockfile ha desaparecido. El gestor de paquetes debe volver a resolver el árbol de dependencias antes de poder siquiera empezar a extraer los archivos. Esto pone a prueba la eficiencia del solver y del analizador de metadatos bajo condiciones de red ideales.

Cada escenario se ejecuta cinco veces, y el canary mantiene el resultado de la mediana. Esa única elección elimina mucho ruido. Un pequeño problema de red transitorio o un breve pico de latencia en el registro no pueden secuestrar la narrativa. El valor atípico se ignora; la experiencia típica se registra.

Las smoke tests superan a los temporizadores vacíos

La velocidad bruta es fácil de fingir si no se verifica el resultado. Un gestor de paquetes podría omitir pasos de postinstalación, corromper algunos enlaces simbólicos o instalar versiones incorrectas y, aun así, publicar una marca de tiempo impresionante. El canary se niega a detenerse en el temporizador. Después de que finaliza la instalación, realmente pone a prueba el código instalado.

Por ejemplo, arranca una aplicación Express y confirma que el servidor comienza a escuchar en el puerto esperado. Si el código no se ejecuta, el benchmark falla por completo. El smoke test transforma la suite de una carrera en una auditoría. Responde a la pregunta que la velocidad por sí sola no puede: ¿realmente funciona la instalación?

La honestidad radical como una característica

El autor del canary escribió tres reglas en el proceso que la mayoría de los autores de benchmarks consideran opcionales.

Mismo campo de juego. Se utilizan flags para normalizar el comportamiento entre las herramientas. Si un gestor de paquetes oculta un fallo de rendimiento tras un ajuste predeterminado, el benchmark lo expone en lugar de permitir que la herramienta parezca buena por accidente.

Arranques en frío genuinos. Antes de cada una de las repeticiones, no solo de la primera, se limpian el caché de npm y el almacén de pnpm. Esa palabra "cada" está haciendo un trabajo pesado. Muchos benchmarks limpian el caché una vez y luego ejecutan cinco instalaciones seguidas. De la segunda a la quinta ejecución no son realmente en frío, y los números se inflan en consecuencia. El canary comienza desde cero cada vez.

Estados de fallo públicos. Cuando una nueva versión rompe algo, el repositorio permanece en un estado de fallo rojo. Se queda ahí, en la página principal, feo y sin resolver, hasta que se lanza una corrección. No hay una supresión silenciosa para mantener el tablero en verde. Esta política obliga a la visibilidad. Un usuario que evalúe herramientas puede ver no solo cuál es la más rápida, sino cuál se mantuvo fiable a lo largo del tiempo.

La capacidad de inspección no es negociable

Un benchmark que no puedes reproducir es un eslogan de campaña. El canary aborda esto con un único script de bash que permite a cualquiera ejecutar cualquier parte de la suite localmente. No necesitas confiar en la red de un proveedor de la nube o en el entorno ajustado a mano por un mantenedor. Si sospechas que los números están mal, puedes generar los tuyos propios.

Esa transparencia también hace que el proyecto sea útil para los mantenedores. Cuando ocurre una regresión, un desarrollador de downstream puede descargar el script, realizar un bisect de las versiones de la herramienta y entregar al equipo de upstream un