"El diseño es el embajador silencioso de tu marca"
- Paul Brand

Yarn vs NPM

Si bien todos conocemos NPM, el gestor de paquetes oficial de NodeJs que ya viene incluido por defecto en la instalación hoy vamos a compararlo con un paquete alternativo que precisamente sirve para eso y que esta en auge ahora mismo.

En primer lugar hay que destacar que precisamente debido al impacto que ha tenido Yarn, NPM se ha puesto las pilas y ha evolucionado mucho en sus últimas versiones (en muchos casos implementando características de Yarn).

Por eso vamos a comparar ambos gestores con las últimas versiones que tenemos disponibles de los mismos a Octubre de 2017:

NPM v5.5.1 (podemos descargarlo aquí)

Yarn v1.1.0 (podemos descargarlo aquí) *

* Hay muchísimas maneras de instalarnos Yarn, de hecho en su página las explican de forma sencilla pero si ya tenemos instalado NodeJs y por lo tanto NPM curiosamente podemos instalar Yarn desde su competidor con este comando:

Al tema, ¿cual es mejor?

Fiabilidad

Este es junto con la velocidad el punto principal que hace que nos decantemos por uno u otro gestor, y Yarn en el pasado simplemente arrasó a NPM en este aspecto, veamos que pasaba.

Cuando NPM instalaba las dependecias que tenemos declaradas en nuestro fichero package.json no lo hace de forma determinista, es decir, que cada vez que ejecutamos el comando npm install el orden en el que instala los paquetes y las dependencias que a su vez estos tienen puede ser diferente cada vez.

Esto plantea dos problemas:

  • El primero es que las carpetas ‘node_modules‘ de distintos miembros de un equipo de trabajo pueden ser distintas.
  • El segundo es que cuando nuestro paquetes tienen una misma dependencia con diferentes versiones, pensemos en que un paquete tira de la v1 de jQuery y otro de la v3, finalmente en nuestro ‘node_modules‘ tenemos una de las dos dependecias instaladas.

Debido al segundo problema si las versiones de estas dependencias no son compatibles al 100% entre ellas nuestro código podría llegar a fallar en:

  1. Nuestro equipo, pero no en el de un compañero del equipo de trabajo.
  2. Nuestro equipo, y volver a funcionar tras forzar la reinstalación de los paquetes.

Lo fastidiado de que esto te pueda pasar es que para dar con el problema a veces te vuelves loco.

Este problemón fue corregido en su dia en Yarn y recientemente en la v5 de NPM.

Para corregir esto Yarn genera en la primera instalación el archivo yarn.lock, un archivo de bloqueo que determina el orden de instalación para garantizar que en todas las máquinas se instalen los mismo paquetes.

NPM permite generar un archivo de bloque usando el comando shrinkwrap, pero esto no lo sabe todo el mundo y además debes acordarte de hacer ejecutarlo.

Ya desde la versión 5 de NPM, se ha añadido un archivo package-lock.json que viene a hacer lo mismo que el de Yarn y que ahora sí permite que los paquetes sean exactamente los mismo cada vez que ejecutes una instalación.

Velocidad

El otro punto estrella de un gestor de paquetes, si bien no estas continuamente instalado dependencias en un proyecto la velocidad es importante y aquí si que es curiosa la enorme diferencia entre ambos.

¿Porque existe tanta diferencia si en principio solo se trata de descargar y desempaquetar librerías desde un repositorio? Principalmente Yarn supera con creces a NPM porque las tareas para procesar los paquetes las ejecuta por fases y en paralelo.

Obviamente que NPM ejecute las tareas de forma secuencial para cada paquete lo ralentiza y aunque en las versiones modernas ha mejorado bastante sus números, sigue muy por debajo de Yarn.

Como lo mejor para verlo es un prueba práctica voy a crearme un proyecto con una serie de librerías y vemos el tiempo que tarda cada uno…

Bien lo primero os dejo un package.json donde he añadido una serie de paquetes algunos de las cuales se que tienen un numero considerable de dependencias:

 

Ahora voy a limpiar la cache de ambos gestores para ver como se comportan…

Sin caché Yarn ha resultado ser más rápido que NPM (17’4s contra 12’85s), no ha sido el doble como muchas páginas dicen, pero si que es una diferencia considerable y por supuesto en un escenario distinto con otras librerías los resultados pueden variar un poco.

Ahora ya no limpio la caché, solamente borro la carpeta ‘node_modules‘ para que vuelva a traerse las dependencias, el resultado es el siguiente en mi caso:

El resultado vuelve a ser favorable para Yarn, y en este caso la diferencia fue mucho mayor, aproximadamente 5 segundos (8’5s contra 3’5s) me parece una barbaridad.

No comprendo porque NPM no cambia su estrategia para gestionar los paquetes viendo que este tipo de pruebas en mayor o menor grado siempre favorecen a su competidor, en definitiva, nadie puede discutir que Yarn es mas rápido.

 

Funcionalidades

Ambos gestores son muy completos y comparten todas las funcionalidades básicas que se espera que tengan, pero es cierto que Yarn a mayores posee algunos comandos útiles que echamos en falta con NPM.

En este link puedes ver los comandos que estan disponibles en Yarn.

De los que tenemos aquí que nos falta en NPM destaca sobre todo el comando why el cual indica porque esta en nuestro proyecto cierto paquete, puede que fuera añadido de forma explicita, mirando el caso de arriba si preguntaramos por «webpack» sería este caso y nos diría…

O igual se trata de una dependecia de algunos de estos paquetes por ejemplo si le preguntara por el paquete «ansi-align» responde esto…

Es decir que viene de las dependencias de Yeoman.

Existen otros que también son muy útiles.

Conclusión

A dia de hoy las últimas versiones de estos paquetes están muy igualados, pero si miras punto por punto aunque la diferencia se ha reducido Yarn sigue ganando a NPM como gestor de paquetes, personalmente es el que uso y estoy contento con los resultados.

La diferencia entre uno y otro no será abismal pero no esta de más conocerlos y trastear un poco con ellos, espero que os gustara el artículo.

The following two tabs change content below.
Especialista en diseño web responsive, programador html5, css3, jquery, php y java.

Latest posts by Óscar Lijó (see all)