Pruebas más rápidas y mejoradas para proyectos JavaScript basados en archivos lock

Durante los últimos meses, hemos trabajado arduamente para mejorar la compatibilidad con archivos lock tanto en la CLI como en la integración con SCM. La nueva funcionalidad ya está disponible en la CLI y se está implementando gradualmente en la web; pronto estará habilitada de forma predeterminada para todas las organizaciones.

Muchos proyectos de Node.js dependen de yarn.lock o package-lock.json para ayudar a los desarrolladores a realizar instalaciones reproducibles y sincronizar los entornos, lo que mejora la colaboración.

No hay duda de que los archivos lock son sumamente útiles: su uso se ha disparado. Hemos trabajado para mejorar la compatibilidad con estos archivos para todos los usuarios y ofrecer resultados de pruebas aún más precisos y un rendimiento mucho más rápido que nunca.

¿Por qué necesitábamos una mejor compatibilidad con archivos lock en la CLI?

Hasta hace poco, recorríamos node_modules para detectar todas las dependencias instaladas en el disco. Esto resultó ser bastante lento y, a veces, impreciso, ya que node_modules solía contener dependencias eliminadas hace mucho tiempo que el proyecto ya no usa. Aunque todos intentamos mantener todo actualizado, simplemente no es práctico eliminar siempre la carpeta node_modules e instalar todo desde cero para garantizar que solo estén presentes los paquetes que realmente usa el proyecto.

Soñábamos con un mundo en el que el usuario no tuviera que instalar sus paquetes para que pudiéramos ejecutar una prueba. Después de planificarlo, creamos una nueva biblioteca node-lockfile-parser que puede recorrer el propio archivo lock y el archivo package.json, en lugar de toda la carpeta node_modules. Como resultado, hoy ofrecemos un rendimiento y una precisión mucho mejores.

Si un proyecto contiene un archivo yarn.lock o package-json.lock, lo detectaremos automáticamente y lo procesaremos como un proyecto basado en archivos lock. Para los proyectos que no tengan archivos lock, se mantiene la compatibilidad anterior.

Nota:

• snyk patch y wizard seguirán requiriendo que esté presente la carpeta node_modules, ya que debemos aplicar los parches directamente en las carpetas de los paquetes instalados.

• Los proyectos de Yarn en versiones de Node anteriores a la 6 también volverán a recorrer node_module. Esto se debe a que una biblioteca de Yarn que se usa para analizar el archivo lock no admite versiones de Node anteriores a la 6.

¿Cómo afecta esto a mis proyectos en la web?

Al importar un proyecto desde GitHub, GitLab o Bitbucket, antes nos basábamos únicamente en el archivo package.json para determinar qué dependencias tenía el proyecto. Esto significaba que debíamos hacer suposiciones sobre la versión exacta de cada paquete instalado en el disco, y siempre suponíamos lo mejor (es decir, la versión más reciente de cada paquete que cumpliera con el rango semver definido en el archivo package.json).

Con la incorporación de la compatibilidad con archivos lock, ahora podemos ofrecer resultados de pruebas más precisos. Actualmente, una prueba de Snyk construye un árbol basado en las versiones exactas resueltas de cada paquete en el archivo lock, lo que significa que podríamos detectar vulnerabilidades que no se habían reportado antes en la próxima prueba de Snyk. No te preocupes: si la opción de autofix PR/MR está habilitada, se actualizará como de costumbre y recibirás notificaciones sobre otras formas de abordar estas vulnerabilidades reportadas.

¿Snyk volverá a generar los archivos lock de mi proyecto?

Todavía no. Estamos trabajando arduamente para ofrecer esta funcionalidad en proyectos de Yarn y npm. No es una tarea sencilla debido a las enormes diferencias entre la lógica interna de resolución de paquetes de Yarn y npm, así como entre sus archivos lock.

Hasta entonces, todos los Pull Requests requerirán cierta intervención manual, igual que hoy. Por eso, en cualquier proyecto con archivos yarn.lock y package-lock.json, será necesario actualizar un archivo lock antes de fusionar el Pull Request si se modificó package.json.