Considera esta alternativa antes de hacer un fork de un paquete npm

¿Te has visto obligado a crear un fork de una biblioteca para hacer un pequeño ajuste? Si lo has hecho, entonces sabes lo difícil que se vuelve mantenerlo responsablemente en el tiempo.

A continuación exploraremos el difícil camino de mantener un fork para poder compararlo con una muy buena una alternativa.

TL;DR

Si los cambios que necesitas hacer en la biblioteca son pequeños, instala patch-package y ahórrate muchos dolores de cabeza.

El difícil camino del fork

Todo comienza cuando encuentras la biblioteca perfecta para resolver un problema, pero te das cuenta de que le falta un pequeño detalle para que funcione exactamente como necesitas … No quieres usar otra biblioteca, así que creas un fork. 🔥

Después de clonar el repositorio en tu equipo, instalar dependencias, aplicar los cambios que necesitas, compilar y probar de alguna manera que lo que hiciste funciona, puedes crear un pull request al repositorio original, cruzar los dedos para que lo revisen y mezclen en un tiempo razonable (si es que lo hacen) y esperar a que publiquen una nueva versión. 😩

Si trabajas como la mayoría entonces no puedes darte el lujo de esperar indefinidamente, así que necesitamos alguna manera de usar los cambios que hicimos ahora.

Tenemos dos opciones principales.

1. Cambiarle el nombre a la biblioteca y publicarla en npm. Una buena idea es usar nuestra organización como scope, así que en nuestra aplicación tendríamos que cambiar la dependencia "some-package": "version" por"@my-org/some-package": "version" .
2. Instalar la dependencia desde github, cambiando "some-package": "version" por "some-package": "github-user/some-package". Ten en consideración que para que esto funcione, el archivo principal del proyecto (indicado por el atributo main de package.json) debe estar bajo control de versión, lo que generalmente no es así porque suele ser un archivo que se genera únicamente al momento de publicar.

Después de todo ese trabajo ya tenemos el cambio aplicado en nuestra aplicación 🎉, así que ahora solo debemos preocuparnos eternamente de mantener el fork actualizado. 🥺

O podemos…

1. Instalar patch-package.
2. Agregar "postinstall": "patch-package" en la sección scripts de nuestro package.json .
3. Aplicar y probar el cambio de la biblioteca modificando node_modules/some-package en nuestra aplicación.
4. Ejecutar patch-package some-package en la terminal.
5. Agregar el archivo generado patches/some-package+version.patch al control de versión.
6. ¡Eso es todo! 🤯

La biblioteca se parchará automáticamente al instalar dependencias, y si necesitas actualizarla a una versión más reciente, patch-package funcionará sin problema mientras no haya conflictos, en cuyo caso tendrás que resolverlo manualmente, volver a ejecutar patch-package some-package y agregar en un commit el nuevo archivo patches/some-package+version.patch .

En un ejemplo del mundo real, agregar este cambio a la biblioteca chart.js :

Genera el siguiente archivo, llamado patches/chart.js+2.7.3.patch :

Podremos quitar este parche cuando cierren un issue que lleva abierto casi 3 años. 👎🏻

¿Cuándo debería usar patch-package?

• Cuando el cambio es pequeño y no quieres lidiar con mantener y publicar un fork.
• Cuando el cambio no tiene mucho potencial de ser un aporte para la comunidad, sino que es más bien una necesidad específica de la aplicación.

¿Cuándo debería hacer un fork?

• Cuando el cambio es demasiado complejo como para escribirlo directamente en node_modules . Recuerda que probablemente trabajarás sobre un archivo generado por un compilador, así que puede ser no tan claro como el código fuente original.
• Cuando el cambio tiene real potencial de ser un aporte para la comunidad, en cuyo caso te animo a crear un pull request y compartir tu trabajo.
• Cuando son muchos los cambios que necesitas aplicar a la biblioteca. En este caso es más conveniente mantener un fork para llevar un orden claro de lo que se está cambiando.

Espero que este pequeño tip te sea de ayuda.

¡Adiós! 👋🏻