Primeros auxilios para las dependencias JavaScript rotas

Me gustaría escribir sobre JavaScript dependencias. Pero empecemos por el principio. Si eres desarrollador de software, probablemente ya sepas que una de tus muchas funciones no es ser otro inventor de ruedas. Al menos, no en la mayoría de los casos. El mundo ha avanzado lo suficiente como para decir que hoy en día existen paquetes para casi todo, haciendo nuestro desarrollo más fácil y eficiente.

Por supuesto, esto no es un estímulo para perder el interés por otras cuestiones: cada paquete tiene un amplio espacio para mejorar y evolucionar. Sin embargo, el objetivo de su empresa es ofrecer un completo producto en un plato justo a tiempo o incluso antes de que se acabe. Los paquetes le ayudarán a cumplir esos planes, aportando npm o hilo en lo alto de la lista de tus mejores amigos, pero ten cuidado: cualquier solución, así como ésta, también puede conllevar riesgos. Y vamos a tratar de describirlo y mostrar una mejor manera de salirse con la suya en el artículo siguiente.

Empecemos con una historia...

Imagina un gran JavaScript proyecto. Los requisitos empresariales obligan a los desarrolladores a utilizar un paquete específico que permita una integración adecuada con otro sistema de un cliente. Y eso está muy bien. MVP se ha traído a tiempo, se ha firmado el siguiente contrato y se sigue desarrollando. El cliente solicita integrar la siguiente parte de un sistema, lo que requiere la actualización de su paquete.

Esta parte va bien, hasta que se disparan las pruebas. Parece que el paquete contiene un error simple, pero inconveniente, que aún no se ha corregido en ninguna versión del producto y se sabe que esto no ocurrirá pronto. No puede arreglar su node_modules directorio - debería ser eliminado del seguimiento de su repositorio, ¡por lo tanto sus colaboradores nunca sabrán nada de sus cambios! Bien, mientras leía esto, probablemente ya ha entendido qué hacer - fork. ¿Pero realmente necesita un martillo así?

Comprenda su problema

Debes ser consciente de si el problema al que te enfrentas te afecta sólo a ti o a una comunidad más amplia. A veces, la gente interpreta la falta de cierta funcionalidad como un error, lo que no siempre es correcto. Por lo tanto, su solución puede no ser aceptada por una comunidad y no ser incluida en un repositorio oficial. Sin embargo, usted todavía lo necesita aquí y ahora. Pues bien, ¡vamos a parchearlo!

Según las notas de la versión del repositorio de github, el paquete de parches ) salió a la venta oficialmente en mayo de 2017. It es una poderosa herramienta, que permite modificaciones dentro de proyecto de dependencia para ser instalado en su node_modules directorio. Algunos pueden decir que esto es una locura - disparar comando de instalación de su gestor de dependencia sobrescribirá los cambios.

Esto es correcto. Sin embargo, un paquete de parches coexiste con npm y hilo perfectamente (debo admitir que funciona ligeramente mejor con npm hasta ahora, puedes leer más en "¿Por qué deberías usar postinstall-prepare con Yarn?" sección del archivo README) y aprovecha al máximo una preparación de script ("script": { "prepare":""}) de tu paquete.json archivo. Patch-package crea literalmente un directorio diff entre sus cambios y el paquete original, almacenado en la carpeta patch de su proyecto actual.

Después de ejecutar el comando install y descargar todas las dependencias, aplica esa diferencia al directorio del proyecto, haciendo una reconstrucción perfecta de tus cambios para todos los colaboradores. Te simplifica la vida, ¿verdad? La solución también tiene algunas desventajas. El parche-paquete no puede arreglar las dependencias de tu paquete ni hacer cambios en paquete.json.

En este caso, puede utilizar la solución de bifurcación. Además, debes considerar el número de cambios que vas a aplicar en tu paquete de dependencias y si crecerán con el tiempo. En caso de que la voluntad - usted debe pensar cuidadosamente cuando se utiliza el tenedor, ya que este es un proyecto propio.

¡No seas egoísta!

El parcheo es una gran manera de arreglar tus dependencias sin crear interminables forks y generar múltiples fuentes de proyecto. Pero siempre debes recordar que el aprovechamiento de la comunidad no debe ser unidireccional. Si encuentras un error o crees que puedes mejorar el paquete que utilizas, considera siempre la posibilidad de ayudar a los demás registrando una incidencia o incluso contribuyendo al proyecto.