Versionado y Publicación de Paquetes con Nx Release

Primero, inicializaremos Nx en un repositorio existente. Luego, usaremos Nx Release para elegir una nueva versión para nuestros paquetes, generar un archivo de registro de cambios a nivel de espacio de trabajo y publicar todos nuestros paquetes en el registro remoto. Luego, cubriremos algunas características adicionales que ofrece Nx Release. Empecemos.

Así que partimos de un monorepo básico de JavaScript. Está utilizando espacios de trabajo de npm y tiene tres paquetes: inventory, requests y users. Lo primero que haremos es inicializar Nx e instalar el complemento NxJS. Así que responderé algunas de estas preguntas. Ninguno de los scripts necesita ejecutarse en orden, así que seguiré adelante y presionaré Enter. Ninguno es almacenable en caché y no voy a habilitar el almacenamiento en caché remoto. Sin embargo, definitivamente te animaría a investigar el almacenamiento en caché remoto para tu propio espacio de trabajo porque puede ahorrar mucho tiempo en CI y en tu flujo de trabajo local. Pero para este ejemplo, me centraré en Nx Release y simplemente lo omitiré.

De acuerdo, ahora voy a abrir el archivo NxJSON y le diremos a Nx exactamente qué paquetes queremos publicar. Haremos esto con la propiedad de proyecto bajo release. Esto es importante porque aunque Nx verá todos los proyectos en tu repositorio, no necesariamente quieres publicar todos ellos porque podrías tener aplicaciones o proyectos de testing finales u otras cosas que no son paquetes npm que deseas publicar. Así que en este caso, tenemos tres paquetes que queremos publicar. Todos están en la carpeta de paquetes, por lo que podemos usar este comodín para representar eso.

De acuerdo, luego vamos a confirmar nuestros cambios hasta ahora. Haremos esto para tener un árbol de trabajo fresco a partir de aquí. Y luego voy a agregar un cambio más. En realidad, voy a solucionar un error grave en los datos de inventario. Y por lo general, es mucho más difícil solucionar un error que simplemente agregar un comentario, pero esto funcionará para lo que necesitamos hacer. Así que voy a confirmar este cambio también. Y ahora podemos ejecutar Nx Release. Así que voy a ejecutar primero Nx Release dry run. Y estas dos opciones son muy importantes. La primera opción de release indica a Nx que esta es la primera vez que ejecutamos Nx Release.

Así que no debes preocuparte por ninguna validación en torno a las etiquetas anteriores de git o asegurarte de que los paquetes existan en el registro remoto. Y la opción de dry run va a realizar esto como una prueba en seco. No va a escribir realmente ningún cambio en el disco. Va a omitir todas las operaciones de git. No va a publicar los paquetes. Solo nos dará una vista previa de lo que sucedería si no usáramos el dry run. Y esto es muy valioso cuando estamos lidiando con operaciones realmente difíciles de deshacer, como crear etiquetas de git, crear lanzamientos en GitHub, publicar paquetes en el registro.

Así que voy a seguir adelante y ejecutarlo. Y voy a elegir una versión menor. Entonces me pedirá qué tipo de cambio es este. Y diré menor. OK. El comando ha terminado. Y volvamos arriba y veamos qué sucedió. El primer paso es el versionado. Detecta cada uno de estos tres proyectos, inventory, requests, users. Lee la versión actual de cada uno como 0.0.1 del archivo package JSON. Y luego escribe la nueva versión basada en ese incremento menor que le dijimos que hiciera. La nueva versión, que es 0.1.0, la escribe en cada uno de los tres archivos package JSON. Ahora, Nx Release siempre mantendrá tus paquetes sincronizados de forma predeterminada. Así que cada vez que quieras incrementar la versión de alguno de ellos, incrementará la versión de todos ellos. Y así siempre estarás lanzando la misma versión para cada uno de tus paquetes. Esto es recomendado porque hace que sea muy fácil para los consumidores de tu paquete determinar qué versiones son compatibles. Porque si todos tienen el mismo número de versión, es muy, muy claro.

Si seguimos desplazándonos hacia abajo, podemos ver los cambios en los archivos package JSON. Y observarás que el paquete requests en realidad tiene una dependencia del paquete users. Y eso también fue actualizado por Nx Release. Y luego, aquí abajo, podemos ver el registro de cambios que se generaría. Así que el registro de cambios tiene una característica, que es la característica en la que agregué los paquetes users, requests e inventory anteriormente. Y luego está la corrección que acabamos de hacer en el paquete inventory.

Y luego al final, obtenemos una vista previa de nuestros comandos git y un recordatorio de que debido a que usamos el dry run, nada de esto sucedió realmente. Fue solo una vista previa. Así que al ver que todo está como esperábamos, puedo continuar y quitar la opción de dry run y ejecutarlo nuevamente. Todavía voy a elegir menor. Y verás que es casi lo mismo, pero obtenemos una solicitud al final. ¿Quieres publicar estas versiones? Ahora, antes de responder a eso, quiero desplazarme hacia arriba y verificar nuevamente. Sí, todas nuestras versiones se han incrementado a 0.1.0. Los cambios en nuestros archivos package JSON se ven bien. El archivo lock se está actualizando porque el archivo lock tiene información sobre la versión de cada paquete en tu espacio de trabajo. Y dado que hemos cambiado eso, necesitamos cambiar el archivo lock. Y luego tenemos este registro de cambios que acabamos de ver y que se ve bien. Y por último, se prepararán, confirmarán y etiquetarán los cambios. Voy a seguir adelante y hacer clic en sí. Y luego se procederá a publicar. Tan fácil como eso. Simplemente ejecuta npm publish en cada uno de estos paquetes. Y verás que se ha publicado en localhost porque en este momento tengo un registro local. Pero esto es simplemente lo que sea tu npm, yarn o cualquier otro registro que tengas configurado.

Y eso es todo. Así que hablemos de un par de funciones adicionales. Mencioné que de forma predeterminada, NxRelease mantendrá todas las versiones de tus paquetes sincronizadas. Bueno, hay otras formas de hacerlo. Definitivamente puedes versionar tus paquetes de forma independiente, donde cada paquete tiene potencialmente una versión diferente y no siempre lanzas todos tus paquetes al mismo tiempo. Eso es algo que NxRelease admite. Solo tienes que agregar un par de opciones de configuración.

Luego también puedes configurar la versionado automática con commits convencionales. Entonces, si no quieres lidiar con un mensaje o especificar explícitamente que quieres una versión menor, mayor o de parche, puedes optar por utilizar commits convencionales para eso. Si tus commits en tu repositorio siguen el estándar de commits convencionales, entonces NxRelease podrá revisar tu historial de Git desde el último lanzamiento y determinar qué tipo de incremento de versión hacer para cada uno de los paquetes.

Algunas otras cosas. NxRelease también puede crear lanzamientos en GitHub. Eso es algo en lo que puedes optar y los archivos de registro de cambios que se generan se cargarán automáticamente para las páginas de lanzamientos en GitHub. Puedes cambiar la representación de los registros de cambios. Entonces, si no te gusta el markdown que se genera de forma predeterminada, puedes agregar una función que reciba todos los datos de los commits y devuelva el markdown que desees usar. Y por último, NxRelease tiene una API programática muy sólida. Entonces, si tienes tus propios scripts para lanzar, tus propios scripts de versionado y publicación, puedes integrar NxRelease en eso. Los tres bloques principales de construcción de NxRelease, versionado, registro de cambios y publicación, puedes importar cada uno de ellos individualmente en tus propios scripts. Puedes usarlos, puedes usar cualquiera de ellos o los tres, como desees para crear tu propio proceso que funcione para ti. Y eso es todo. Gracias por escuchar. Por favor, consulta la documentación de Nx.dev que explicará todo esto aún más. Se detallarán las diferentes opciones de configuración y los diferentes casos de uso. Y espero verte en el futuro.