Selección de las dependencias correctas: una guía práctica completa

Si fuera chef en un restaurante exclusivo con estrella Michelin, ¿compraría verduras y carne de fuentes aleatorias no verificadas? El costo de casi cualquier proyecto promedio se mide en cientos de miles o incluso millones de dólares. Creo que nuestra industria debería tener el mismo enfoque que los restaurantes.

La primera pregunta que debe hacerse de inmediato: ¿realmente necesita una nueva dependencia? ¿Se podría resolver el problema utilizando el entorno actual, como el idioma o las bibliotecas instaladas? Por ejemplo, no es necesario instalar una biblioteca adicional para generar UUID. Node.js y los navegadores lo admiten desde el primer momento: crypto.randomUUID()

La segunda pregunta: ¿necesita toda la biblioteca? Por ejemplo, si solo necesita un menú desplegable, ¿vale la pena instalar algo como Bootstrap? ¿Quizás es mejor limitarse a una sola biblioteca enfocada con un componente desplegable sin estilo de Radix UI ?

Bueno. Tenemos algunos candidatos en mente. Entonces, ¿cómo elegimos el correcto?

¿Un README bellamente formateado? ¿Un nombre conocido? ¿Más bifurcaciones, estrellas y descargas que otros? Desafortunadamente, estos factores por sí solos no son suficientes. Aquí, estamos seleccionando un proveedor de servicios. Queremos que cualquier incidencia que surja se resuelva rápidamente, que la funcionalidad se mantenga actualizada y, sobre todo, que el servicio sea seguro y fiable. Las métricas externas simples no siempre indican la calidad o la idoneidad a largo plazo. Antes de instalar lo que hemos encontrado en el catálogo de repositorios, sería genial visitar el repositorio de GitHub y analizar su contenido.

He preparado una lista de criterios que he estado utilizando durante los últimos años. Espero que te ayuden a elegir las bibliotecas más adecuadas. Es esencial considerarlos exhaustivamente y, en algunos casos, hacer concesiones al elegir entre ellos.

Descargo de responsabilidad: no estoy criticando las bibliotecas mencionadas a continuación ni tratando de desalentar su uso. En algunos casos, he omitido nombres intencionalmente para centrarme en el ejemplo del criterio manteniendo la precisión de los hechos.

1. Seguridad

¿Qué tan seguro es usarlo? Puede sonar a ficción, pero sí, las dependencias pueden ser peligrosas. Por ejemplo, se agregó una característica interesante a una biblioteca con 500k descargas: intenta reemplazar todos los archivos en la computadora con ❤️ si su dirección IP se encuentra dentro de un rango específico.

Un hecho interesante es que esta dependencia se usó en vue-cli . ¿Cómo podemos descubrir tales problemas? Consulte la página de problemas o intente buscar en Google por el nombre de la biblioteca. Por lo general, dicha información surge rápidamente.

2. Mantenimiento

¿Cuándo fue el último lanzamiento? ¿Con qué frecuencia ocurren los lanzamientos? Los lanzamientos regulares aseguran que los problemas se resuelvan y las actualizaciones admitan tecnologías en constante cambio. En el contexto del desarrollo móvil, los lanzamientos regulares también aseguran que el proyecto se compile con éxito.

Aquí hay un ejemplo del mundo de Go: los autores de una biblioteca con 18.200 estrellas decidieron dejar de mantener su dependencia y la archivaron. Esto significa que, en unos años, la falta de soporte y actualizaciones se convertirá en un problema. Ahora imagine instalar una dependencia similar sin verificar primero GitHub. Es como comprobar la fecha de caducidad de los productos.

Aquí hay un ejemplo de buenos lanzamientos frecuentes:

3. Problemas abiertos / cerrados

1. ¿Cuál es la proporción de problemas abiertos a cerrados? ¿Qué tan dispuestos están los autores a aceptar cambios? Es posible que necesites contribuir con algo algún día. Por ejemplo, esta biblioteca es bastante popular y tiene un 98 % de números cerrados. Solo 18 están abiertos.

   

   
   

2. ¿Qué tan rápido se resuelven los problemas críticos? Una vez, elegí un ORM con 31k estrellas, pero en algún momento nos encontramos con un problema que nos bloqueó. Tuvimos que buscar soluciones alternativas y eventualmente cambiar a otra solución. Desafortunadamente, han pasado casi cuatro años y el problema aún no se ha resuelto.

   

   Dichos problemas se pueden identificar ordenándolos por los más comentados.

   
   

3. ¿El proceso de contribución ha sido organizado por los creadores? ¿Existe un flujo de trabajo claro y definido? Por ejemplo, los creadores de Next.js grabaron incluso un video de 40 minutos sobre su proceso de contribución.

   
   

4. Calidad del código

Sí, puede haber mucho código, pero siempre es posible examinar sus diferentes partes. ¿Cómo está organizado el proyecto? ¿Es comprensible, está bien estructurado y se aplican buenas prácticas? Cuanto peor esté escrito el código, mayor será la probabilidad de que el proyecto desaparezca en el futuro. Muchos candidatos pequeños fueron eliminados en esta etapa para mí.

5. Cobertura de prueba

¿La biblioteca tiene exámenes? ¿Cuál es la cobertura de la prueba? ¿Cómo se escribieron las pruebas? Incluso si los mantenedores revisan las solicitudes de fusión, existe la posibilidad de que algo se pase por alto. Hay muchas personas diferentes que contribuyen a la biblioteca. Normalmente, la información de cobertura de la prueba se muestra en insignias en la parte superior del repositorio. Sin embargo, si no es así, siempre podemos buscar pruebas en el proyecto. Por ejemplo, la familia de bibliotecas formatjs tiene una excelente cobertura de pruebas e incluye varios tipos de pruebas.

6. Tamaño de la biblioteca

Las aplicaciones móviles a menudo tienen grandes tamaños de dependencia y la aplicación completa puede tener incluso más de 200 MB, lo que puede causar problemas durante las descargas de la red celular y consumir mucho espacio de almacenamiento. Esto es especialmente problemático para las aplicaciones CSR de front-end, donde las velocidades lentas de Internet pueden aumentar drásticamente los tiempos de carga.

Para proyectos web, existe una gran herramienta para determinar el tamaño de los paquetes: https://bundlephobia.com . Por supuesto, la representación del lado del servidor y la agitación del árbol pueden reducir el tamaño, pero esto debe verificarse siempre.

Un ejemplo popular son las bibliotecas de manipulación de fechas. La funcionalidad proporcionada por dayjs (2,9 KB) podría ser suficiente, eliminando la necesidad de instalar moment.js (72,1 KB) o date-fns (26,8 KB).

7. Número de Dependencias

Todos los puntos enumerados anteriormente se multiplican, hasta cierto punto, por el número de dependencias en todo el árbol de dependencias del proyecto. Una gran herramienta para verificar el árbol de dependencia completo: https://npm.anvaka.com

8. Licencia

¿Alguna vez ha pensado en esto? Yo tampoco. Por ejemplo, las licencias MIT y Apache 2.0 permiten el uso gratuito de bibliotecas en proyectos comerciales, mientras que algunas licencias GPL v2 tienen requisitos y restricciones específicas. En uno de nuestros proyectos, un abogado preparó una tabla para verificar todas las licencias de nuestro árbol de dependencia. Entonces, si ve algo inusual en una licencia, es mejor consultar a un abogado para evitar problemas durante una auditoría. Podemos extraer todas las licencias de las dependencias npm existentes utilizando la utilidad legalmente . PD: no soy abogado, y esto no fue un consejo legal. Es un caso raro y especializado que algo no sea adecuado debido a la licencia, pero aún es posible.

¡El fin!

¡Gracias por leer mi artículo! El punto clave fue mostrar ejemplos del mundo real de que la toma de decisiones superficial y rápida a veces puede conducir a no ser la mejor opción. Al considerar estos criterios, podrá tomar una decisión más informada.

Por favor, siéntase libre de dejar cualquier comentario o sugerencia que pueda tener. No dudes en compartir tu experiencia en los comentarios también. Tus gustos y comentarios me inspiran a escribir nuevos artículos. Feliz cocina :)