Como desarrolladores de Javascript, todos conocemos dos dependencias diferentes en nuestros proyectos, dependencias y devDependencies, pero ¿qué pasa con las peerDependencies?

En esta serie, examinaremos esta dependencia menos común en Javascript. Estudiaremos qué son, qué necesito saber como usuario de una biblioteca y cuáles son las mejores prácticas para los autores de la biblioteca.

¿Qué son las dependencias en NPM?

Recapitulemos los diferentes tipos comunes:

• dependencias: estas son las herramientas utilizadas en su aplicación; un buen ejemplo es reaccionar, angular y expresar. Cuando su aplicación esté en producción, el código de las bibliotecas de las dependencias se ejecutará internamente y alimentará su aplicación.

• devDependencies: utilizará estas utilidades para crear su aplicación. Aquí encontrará bibliotecas para compilar o analizar su código y bibliotecas para ejecutar su prueba.

¿Qué son las dependencias entre pares?

Los autores especifican bibliotecas específicas como peerDependency cuando requieren que se instalen en el espacio de trabajo/proyecto para que todo funcione como se esperaba. Le dicen a NPM (y a los desarrolladores que instalan la biblioteca) que el paquete requiere la versión específica (o rango de versiones) de otro paquete para funcionar correctamente. Aún así, el usuario es responsable de instalar y administrar esa dependencia.

Imaginemos un ejemplo: está creando una utilidad para su marco favorito, que debe instalarse en el entorno donde se ejecutará su biblioteca. La forma de especificar con precisión este escenario es utilizar la función peerDependency de NPM. Proporciona una guía clara para la perfecta integración de su biblioteca.

Esta práctica es particularmente común en bibliotecas que funcionan como "complementos", ya que necesitan indicar los requisitos del espacio de trabajo para una funcionalidad adecuada.

Ejemplo real de dependencia entre pares

Analicemos una biblioteca React popular, react-datepicker; Si observamos cómo se ve su paquete.json hoy, podemos ver que necesitamos al menos la versión de React ^16.9.0 para que el selector de fecha de reacción funcione correctamente.

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

Si no cumplimos con este requisito, surgirá un comportamiento inesperado.

Los desafíos que abordan las dependencias de pares

Los conflictos de versiones ocurren cuando los paquetes de un proyecto dependen de diferentes versiones de la misma biblioteca. Esto puede provocar errores, especialmente en bibliotecas como React, donde compartir la misma instancia es crucial para la gestión del estado y la comunicación de componentes. Sin peerDependencies, se podrían instalar varias versiones de la biblioteca, lo que provocaría un comportamiento inesperado.

Para evitar estos problemas, peerDependencies permite a los autores de paquetes especificar qué versión de una dependencia requiere su paquete sin instalarlo directamente. Esto transfiere la responsabilidad al desarrollador que utiliza el paquete, asegurando que instale una versión de dependencia única y compatible. Por ejemplo, bibliotecas como reaccionar-datepicker y reaccionar-router usan peerDependencies para garantizar que funcionen sin problemas con la misma versión de React en el proyecto.

Otro ejemplo

Imagina este escenario: estás creando una biblioteca para compartir un operador sofisticado para rxjs. Si configura rxjs como una dependencia en lugar de peerDependency, su biblioteca instalará su propia versión de rxjs. Puede que esto no parezca gran cosa al principio, pero en realidad puede generar conflictos de versiones.

Si el proyecto que instala su biblioteca ya usa una versión diferente de rxjs, podría causar problemas importantes. La aplicación podría terminar con dos instancias de rxjs (una de su biblioteca y otra del propio proyecto). Dado que rxjs depende en gran medida de suscripciones y observables compartidos, tener dos versiones ejecutándose simultáneamente puede resultar en un comportamiento impredecible, como que las transmisiones no se sincronicen correctamente o que falten eventos.

Al utilizar peerDependencies en su lugar, puedes evitar este problema. Su paquete le indicará al proyecto que espera que esté presente una versión específica (o un rango) de rxjs, pero no instalará su propia versión. De esta manera, el proyecto utilizará una única versión de rxjs compartida por su biblioteca y otras partes del código base, asegurando que todo funcione sin problemas y en armonía.

Conclusión

peerDependencies no se analicen con tanta frecuencia como las dependencias o las devDependencies, pero desempeñan un papel fundamental para garantizar la compatibilidad y evitar conflictos de versiones en proyectos complejos. Al definir claramente qué versión de una dependencia compartida necesita una biblioteca sin instalarla directamente, las peerDependencies permiten a los desarrolladores mantener el control sobre el entorno de su proyecto.

El objetivo de esta primera publicación es crear una buena base de comprensión de las dependencias entre pares. En el próximo capítulo de esta serie, exploraremos de una manera más práctica los diferentes aspectos de peerDependencies como usuario de bibliotecas con peerDependencies, cómo superar problemas comunes y cómo se comportan en diferentes administradores de paquetes javascript.