Dependencias de Configuración en pnpm

Entonces, sí, de hecho renombré esta característica a config dependencies después de enviar la charla, porque era realmente difícil de pronunciar. Así que sí. Bien. Quiero hablar sobre una nueva característica que salió en la versión 10 de PNPM. Este es un nuevo tipo de dependencia llamado config dependency. Y mostraré algunos ejemplos de cómo puedes usarlos. Y también mostraré algunos hooks que puedes usar con PNPM para cambiar su comportamiento durante la ejecución. Y en combinación con config dependencies, puedes crear tus propios plugins personalizados para PNPM.

Ya fui presentado. Así que solo unas pocas palabras. Soy el mantenedor principal de PNPM desde 2016. Actualmente trabajo en Bit, que es como una alternativa a GitHub, se podría decir. Pero en lugar de repositorios, tenemos componentes. Y en Bit, trabajo en la gestión de dependencias. Utiliza PNPM bajo el capó para la instalación. Y me permite trabajar en las características de PNPM también. Y vivo en Hungría.

¿Has oído hablar de PNPM? Espero que sí. Bien. ¿Y usas PNPM? Bien. Bueno... Bueno que aún no cambiaste a otra cosa. Así que PNPM es un gestor de paquetes alternativo escrito en JavaScript. Y creo que su característica más llamativa es que utiliza un almacén central direccionable por contenido. Y cuando instalas este PNPM, los archivos dentro de los módulos de Node son enlaces duros a archivos en este almacén central. Y así, tus módulos de Node usan menos espacio en disco en la computadora. Pero PNPM también es una muy buena opción para monorepos. Si revisas nuestro sitio web, tenemos una lista de nuestros usuarios y algunos de los proyectos populares de código abierto que utilizan monorepo actualmente usan PNPM. Pero a veces un monorepo no es suficiente. Las empresas suelen tener múltiples monorepos o una mezcla de monorepos y repositorios.

Como repositorios de un solo paquete. Y cuando tienes múltiples repositorios, pierdes un poco las ventajas de centralizar toda tu configuración, tus .files, cosas así. Y hay muchas cosas que podrías querer centralizar en términos de gestión de dependencias. Como podrías tener tus overrides que usas en toda la empresa, o podrías tener una lista de dependencias confiables, o algunas configuraciones específicas que prefieres usar con PNPM. O podrías tener un conjunto de archivos de parche, porque PNPM y también Yarn soportan parchear tus dependencias con archivos de parche.

Y no sé si hay una solución bien conocida para esto. Sé que hay algunas herramientas que sincronizan automáticamente archivos a través de repositorios. Así que básicamente es copiar y pegar. Y tuvimos muchas solicitudes para resolver este problema. Y cuando comencé a trabajar en BIT, me inspiró mucho cómo BIT resolvió este problema. En BIT, tenemos componentes en lugar de repositorios, y cada componente es completamente portátil e independiente. Así que cada componente realmente envía su propio conjunto de configuraciones.

Y la forma en que se resuelve es mediante un tipo especial de dependencia, que se llama componente de entorno. Como puedes ver, tenemos nuestros componentes en la nube, y cuando desarrollas alguna característica, puedes importar dinámicamente esos componentes que deseas cambiar. Y cada componente puede incluso tener su propia pila. Algunos componentes pueden ejecutar pruebas con Jest, otros pueden usar VTest. Y esto es posible gracias a estos componentes de entorno que se instalan muy temprano. Eso es todo sobre BIT. Así que en PMPM, implementamos algo similar, y lo llamamos config dependencies. Así que este es un tipo completamente nuevo de dependencia, que se instala antes que todos los otros tipos de dependencias sean instalados.

Así que antes de las dependencias de producción, dependencias de desarrollo y dependencias opcionales. Y porque se instala tan temprano, nos permite conectarnos a cómo funciona PMPM con estas config dependencies. Estas dependencias son algo limitadas, porque no queremos que la gente cree config dependencies complejas y haga que PMPM sea más lento. Así que actualmente, las config dependencies no pueden tener dependencias propias. Si necesitas dependencias, necesitas empaquetarlas con tu config dependency, como con ESBuild. Y además, las config dependencies no pueden ejecutar ningún script de ciclo de vida como post installs.

Para instalar una config dependency, puedes usar una nueva bandera que añadimos al comando add. Así que puedes ejecutar pmpm-add-config y luego el nombre del paquete. Esto es como un paquete regular alojado en el registro de MPM. Y cuando ejecutas este comando, se guarda una nueva entrada en el archivo de configuración de PMPM. Es el pmpm-workspace.yaml. Y contendrá el nombre del paquete, la versión y el checksum de integridad. Así que no se añadirá ninguna entrada al archivo de registro, pero porque siempre se guardará una versión exacta en este archivo de configuración, no necesitamos cambiar el archivo de registro.

Entonces, ¿para qué son buenas estas config dependencies? Les mostraré algunos ejemplos. Y si tengo tiempo, tal vez incluso una pequeña demostración. O simplemente estaré cambiando entre diapositivas y demostración. Por ejemplo, puedes usar config dependencies para enviar tus archivos de parche. Así que digamos que tienes algún parche para React y quieres usarlo en varios repositorios. Así que en lugar de copiar los archivos de parche, podrías crear una config dependency y publicar el archivo de parche con esta config dependency. Y luego tengo un ejemplo aquí. Bien. Pero este no es React, sino un paquete diferente. Pero he parcheado este paquete con un archivo de parche de una config dependency. Puedes ver mi pmpm-workspace.yaml. Contiene esta config dependency. Puedes verificar realmente este repositorio en GitHub si estás interesado. Tengo algunos ejemplos. Y estoy cargando el archivo de parche para isod desde esta config dependency. Y si ejecuto este paquete isod ahora, puedes ver que imprime el mensaje, que fue añadido con el archivo de parche. Así que si voy al contenido del paquete, puedes ver que tiene console.log aquí, que no está presente en el paquete original.

También podrías cargar, permitir listas de dependencias que son confiables para ejecutar scripts de ciclo de vida. En pmpm versión 10, ahora prohibimos que las dependencias ejecuten scripts durante la instalación. Esto fue introducido inicialmente por BAN, y seguimos su ejemplo. Pero ahora es... Esto se vuelve difícil de gestionar esta lista de dependencias confiables. Así que puedes crear una config dependency con la lista que tu organización confía, y luego referenciar la lista a través de esta configuración, solo archivo de dependencias de construcción. Mantenemos tal lista en nuestra organización llamada trusted-debs. Esto es actualmente solo un copiar-pegar de la lista utilizada por BAN.

Oh, mierda. Boom. Despeje serial allí. Así que en este paquete, estoy usando la config dependency trusted-debs, y puedes ver que esbuild ejecutó su script postinstall. Pero si ejecuto core.js, no ejecutará su script postinstall porque no está en la lista. Bien. Puedes ver aquí cómo se ve en el workspace de pmpm.

Bien, como mencioné en el título, también hay hooks que puedes usar para cambiar el comportamiento de pmpm. Y tenemos... Y al mover los hooks a config dependencies, realmente puedes crear plugins. Plugins es algo que también YARN soporta. Y YARN lo soporta desde hace mucho tiempo, por lo que tiene algunas ventajas sobre los hooks y plugins de pmpm. De hecho, los plugins de YARN son... Y de hecho tenemos al mantenedor principal de YARN aquí, y le hice algunas preguntas sobre los plugins de YARN antes de la charla, así que verificó que esto no es una mentira. Los plugins de YARN son más poderosos. Incluso puedes crear nuevos comandos con los plugins de YARN. Eso no es posible con los hooks de pmpm. Hay un par de plugins de código abierto para los plugins de YARN, y hay una herramienta que puedes usar para construir tus plugins de YARN, por lo que no necesitas configurar esbuild tú mismo.

Pero la desventaja de los plugins de YARN es que actualmente no hay comandos para instalarlos en tu proyecto, por lo que necesitas obtener el archivo para el plugin de YARN tú mismo, y luego necesitas mantenerlo actualizado tú mismo. Y no hay hooks simples que puedas usar. Siempre necesitas declarar un plugin de YARN, lo cual es más trabajo que los hooks de pmpm. Básicamente, los hooks de pmpm se cargan desde un archivo pmpm file.js. Y hay dos tipos diferentes de hooks. Hooks avanzados y hooks simples. Con los hooks avanzados, puedes crear fetchers personalizados, importadores, resolutores, por lo que puedes básicamente cambiar lo que se instala y desde dónde. Un ejemplo de algo que utiliza hooks avanzados es StackBlitz. StackBlitz ejecuta pmpm en un contenedor web, y crearon estos fetchers e importadores personalizados para hacer que pmpm sea realmente rápido dentro del contenedor web. Y los hooks simples pueden cambiar el manifiesto del paquete durante la instalación y cambiar configuraciones.

Así que seré rápido ahora, porque el tiempo es... No queda mucho tiempo. Así que uno de los hooks es el hook update.config, el hook simple. Y este hook permite cambiar el objeto de configuración de pmpm durante el tiempo de ejecución. Por ejemplo, en este ejemplo, puedes ver que establecemos una anulación para Socks, porque Socks tiene una vulnerabilidad en todas las versiones anteriores a la 2.8. De esta manera, puedes corregir vulnerabilidades y compartir estas correcciones en toda tu organización. Solo instala esta config dependency. Puedes cambiar la configuración predeterminada de pmpm para ser más estricta, por ejemplo, porque la configuración predeterminada te permite mucho. Son buenas para las personas que recién comienzan a usar pmpm. Pero si deseas ser más estricto, puedes tener tus propias políticas, crear una config dependency y compartirla. Mantenemos una config dependency llamada better defaults, que podemos usar, y hará que pmpm sea más estricto, y es mejor para usuarios avanzados. Además, cualquier cambio importante en pmpm podría llegar primero a esta config dependency. También puedes compartir catálogos de versiones con este hook. Espero que hayas oído hablar de los catálogos de versiones, pero si no, échales un vistazo. Otro hook simple es el hook read package, que te permite modificar el manifiesto del paquete durante la instalación. Así que si a algún paquete le falta una dependencia, por ejemplo, puedes extender el sujeto de la dependencia aquí, y se instalará. En este caso, pmpm-to-agent carece de un debug en sus dependencias, y básicamente podemos verificar si está allí, y si no, lo editamos. Otro caso de uso es crear listas de permitidos o listas de bloqueados de paquetes. Tal vez tu organización tenga un proceso para permitir nuevos paquetes. Puedes usar este hook para verificar el paquete que se instala y lanzar un error si no lo deseas.

Este es otro ejemplo de una config dependency que se utiliza en el hook read package. Lo mantenemos. Es un type fixer, y básicamente intenta ver si a un paquete le falta una type dependency, y si le falta, la añadirá a dependencies o peer dependencies y corregirá cualquier problema de type script que puedas tener con pmpm.

Bien. Estoy a tiempo. Si quieres ver los ejemplos, puedes verlos en GitHub. Gracias.

Bien. Tenemos un par de preguntas que llegaron en Slido, así que vamos a repasarlas. Una de ellas es, ¿puedes proporcionar ejemplos de implementaciones de pmpm hook que mejoren la calidad de vida? Creo que mencionaste un par, pero tal vez... Sí, mencioné un par. ¿Qué crees que es lo más importante para otras personas en cuanto a la vida- Sí, creo que compartir tus configuraciones con este update config hook, así que cualquier preferencia que tengas, la pondría en este hook y la publicaría como una config dependency, y luego puedes usarla como una dependencia en cualquiera de tus proyectos. Es muy conveniente. Ya lo uso en mis proyectos. Perfecto. Gracias.

Veamos. Muy bien. Veamos cuál, porque hay un par de preguntas sobre características y demás. Ahí vamos. ¿Pueden ser maliciosos los paquetes de config? Tal vez un error tipográfico o tipos llamados paquete que sobrescriben la lista de allow post install? Cualquier cosa puede ser maliciosa. Cualquier cosa puede ser maliciosa es como, sí. Tal vez sea un poco más fácil verificar si es bueno o no, porque es un solo paquete. No puede tener dependencias propias, pero seguro que necesitas ser cauteloso con ellos. Correcto. Exactamente. ¿Qué significa la P en pmpm? Es performant npm. Wow, me encanta.

Bien. Ese es un pequeño comentario salado. Muy bien. Como una pregunta para mí mismo, tú como mantenedor, ¿cómo te mantienes trabajando en un proyecto como este? Desde que me uní a BIT, es mucho más fácil, porque BIT se beneficia de pmpm. Usan pmpm bajo el capó para su CLI. Antes de eso, trabajé en otra empresa, una empresa de productos, que no se preocupaba por ello, y usé solo mi tiempo libre.

Así que fue realmente difícil. Pero para mí, funcionó porque encontré un buen trabajo bien pagado. Así que fue una gran inversión que tuve que pagar. Pero ahora es más fácil.

¿Tienes más colaboradores que se unieron a ti en el camino que te ayudan a construir esta cosa? Sí, tenemos. ¿O estás buscando a alguien que te ayude a construir el proyecto? Tal vez haya algunas personas en la audiencia que puedan estar interesadas. Sí, creo que hay múltiples empresas que estarían dispuestas a contratar a una persona que tenga buen conocimiento de la base de código de pmpm. Conozco algunos nombres importantes. Pero es algo arriesgado porque es un área de especialización muy estrecha.

El beneficio es que los modelos de lenguaje grandes te reemplazarán tal vez un poco más tarde, si estás tan especializado. Pero supongo que no se necesitan tantas personas en esta área. Pero tenemos una persona de Vietnam. Su nombre es Kai, quien también trabaja a tiempo completo en pmpm. También está patrocinado por BIT. Muy bien. Gracias por eso.

¿Existen herramientas para migrar desde npm workspaces a pmpm para monorepos o algo así? ¿De npm a pmpm? Creo que hay una empresa que crea mods, Codemods. Y creo que tal vez crearon algunos mods para eso. Y tal vez incluso lo tengamos en nuestra documentación. Pero no tenemos nada incorporado en pmpm para esto. Muy bien. Gracias por eso.

Veamos, ¿qué más? La gente todavía quiere preguntar sobre, ya sabes, características infrautilizadas o cualquier otra cosa que realmente quieras destacar. Oh, esto es tal vez, como, una pregunta un poco controvertida. ¿Por qué algunos de los ejemplos que mencionaste no están alojados en BIT? Sí, BIT no es tan popular en este momento. Como que la gente está más acostumbrada a GitHub. Así que es como... Siento que es solo un beneficio, ya sabes, como que no están acoplados juntos. Puedes usar uno o ambos, pero no necesitas... Y también, como que es muy caro dar gratis... ¿Cómo decirlo? Porque GitHub es utilizado por código abierto. Así que gastan como millones para estos proyectos de código abierto porque son gratuitos. Y BIT es una empresa pequeña, no puede dar todos estos niveles gratuitos a proyectos de código abierto. Sí. Así que es más un producto a nivel empresarial, diría yo. Bien, creo que eso es bastante justo.

Veamos. Hagamos una pregunta más y luego cambiamos de orador. Veamos. ¿Cómo impones restricciones en los paquetes y su versión específica? Así que puedes crear este gancho de paquete, y se llama en cada paquete que se resuelve durante la instalación. Y puedes poner una nueva declaración y verificar el nombre del paquete y la versión. Y si no permites algo, puedes lanzar un error. Sí. Así es como. Muchas gracias. Y muchas gracias de nuevo por tu charla. Haremos un pequeño cambio aquí para el próximo orador. Sí. Gracias. Muchas gracias.