Desbloqueando el Poder del Dependency Graph

Bienvenidos a todos. En esta charla, revisaremos algunas ideas sobre cómo desbloquear el poder del gráfico de dependencias, junto con algunos ejemplos de cómo aprovecharlo usando el cliente de Vault. Soy Rui Adorno, soy ingeniero fundador en Vault, donde estamos construyendo el futuro de los paquetes de JavaScript. Antes de eso, trabajé en NPM Inc. y eventualmente me mudé al equipo de NPM CLI en GitHub. Antes de unirme a Vault, pasé dos años en Google trabajando con el SDK de JavaScript, lo que me dio otra ronda de experiencia como usuario final antes de volver al mundo de la cadena de suministro de JavaScript. He estado trabajando en el espacio de gestión de paquetes de Node.js durante años, y lo que quiero compartir hoy proviene de esa experiencia.

Bueno, las dependencias son los bloques de construcción de los proyectos de JavaScript, pero la estructura de datos resultante, un gráfico que forman, ha sido históricamente infrautilizada por el ecosistema de herramientas. Comprender cómo se relacionan estas dependencias y por qué incluso existen sigue siendo sorprendentemente difícil. Cada proyecto tiene dependencias. Cada vez que ejecutas una instalación, el gestor de paquetes resolverá la dependencia, creando una estructura de datos de gráfico que debe resolverse, desduplicarse, antes de finalmente escribir todos los archivos en el disco. Pero después de todo, la estructura de datos del gráfico se ignora para casi todos los demás comandos. Y esta estructura de datos del gráfico debería tratarse como un ciudadano de primera clase.

¿Cómo se ve una herramienta que trata la estructura de datos del gráfico como un ciudadano de primera clase? Bueno, deberías exponer esa estructura de gráfico, luego hacer uso de una sintaxis para permitir consultar el contenido de la estructura, y finalmente, usar la comprensión de la estructura del gráfico en todo tipo de operaciones del proyecto. Así es como realmente se ve el gráfico de dependencias. No una lista plana de carpetas en Node modules, sino probablemente un gráfico cíclico. En este caso, mi aplicación depende de Express, React y TypeScript. Express depende de BodyParser, XSAP, y así sucesivamente. Y cuando hacemos zoom, nos damos cuenta de que cada nodo lleva su metadato completo, seguridad, relaciones, todo debería ser consultable. Y esto es lo que vive dentro de cada nodo. No solo el nombre de la versión, sino también hashes de integridad, fechas de publicación, información del autor, detalles de seguridad, Cuando mantienes el gráfico, todos estos metadatos son consultables. Puedes preguntar, muéstrame todos los paquetes publicados antes de una cierta fecha o muéstrame todo por un autor específico, porque todo está ahí en el gráfico. Aquí, quería introducir este concepto de la sintaxis del selector de dependencias, que es algo que hemos estado usando durante mucho tiempo. Aquí, quería introducir este concepto de la sintaxis del selector de dependencias. Lo llamamos DSS para abreviar. Está basado en selectores CSS, y nos ayuda a responder preguntas complejas sobre dependencias, su relación y metadatos. Puedes ver cómo encaja muy bien con el modelo CSS. Comencemos con algunos ejemplos concretos. Es más fácil de visualizar. Comenzando aquí con el operador estrella, solo está seleccionando todos los nodos en el gráfico.

En este caso, todos están seleccionados, así que todo está en amarillo aquí. Puedes ver cómo este gráfico son las conexiones entre cada nodo, que es la declaración de dependencia de cada uno de estos paquetes, y la realización de ese paquete, que es cada nodo que estamos viendo coloreado de amarillo aquí. Para mostrar un poco más cómo se ve esta sintaxis de selector de dependencias, déjame comenzar con algunos ejemplos de otros selectores útiles. En este ejemplo aquí, estamos viendo common root. Es básicamente el selector que te permite seleccionar la raíz del proyecto. Pasando a este aquí, estamos comenzando a combinar diferentes partes de la sintaxis para formar un selector más complejo para consultar el gráfico. En este caso, estamos usando common workspace y luego una pequeña flecha y estrella, que básicamente lo que estamos haciendo aquí es que estamos seleccionando las dependencias directas de los workspaces. Esta sintaxis debería sentirse muy natural para las personas acostumbradas a la sintaxis CSS, así que esto es básicamente lo que está sucediendo aquí. Comenzando desde workspace, dame las dependencias directas. Puede ser cualquier cosa. Es solo una estrella, ¿verdad? Podemos ver que, en este diagrama aquí, solo tenemos los elementos en la parte inferior coloreados de amarillo porque han sido seleccionados, y podemos ver sus padres. Podemos ver cómo se conectan hasta la raíz del proyecto.

Aquí, en este ejemplo, vamos a seleccionar una dependencia específica por nombre, así que estamos usando almohadilla y el nombre de la dependencia. En este caso, estamos usando almohadilla es exe, y podemos ver el nodo en la parte inferior y todos sus ancestros hasta la raíz del proyecto. En este caso, exe es una dependencia directa de which, que es una dependencia de mi workspace de servidor. Seleccionar dependencias directas de workspace y root. En este ejemplo, vamos a combinar estos dos ejemplos anteriores que hemos visto antes, pero estamos usando una coma para separar y básicamente obtener los resultados de ambos selectores al mismo tiempo. En este ejemplo aquí, puedes ver que vemos todas las dependencias directas de los workspaces están resaltadas, y también estamos incluyendo exe en la parte inferior allí como una dependencia de which porque ha sido seleccionada directamente por su nombre. En este caso, estamos viendo aquí el cliente de workspace y el servidor de workspace. Están siendo combinados usando el selector is, y estamos obteniendo las dependencias directas de estos workspaces. Así que, puedes ver aquí en el diagrama resultante, terminamos solo con los workspaces de servidor y cliente, y en la parte inferior podemos ver sus dependencias. Y también hay selectores basados en información de seguridad que nos permiten filtrar basado en metadatos de seguridad proporcionados por Socket. Y en este caso aquí, estamos usando el score, el selector de score, que puntúa básicamente metadatos y un agregado de diferentes puntos de datos que Socket recopila. Y en mi ejemplo aquí, quiero poner el listón alto en mi proyecto, quiero saber qué paquete dentro de mi proyecto tiene una puntuación inferior a 80. Y en este caso aquí, obtuve este paquete English Days que está siendo resaltado como una dependencia directa del workspace de cliente. De esta manera puedo filtrar basado en todos estos metadatos de seguridad que son proporcionados por Socket. Y aquí al lado, podemos ver un poco de cómo se ve ese dato. En este ejemplo, estoy usando el selector not para simplemente negar el selector que está dentro de él. Así que, en este ejemplo, quiero obtener todos los paquetes en mi proyecto que no tienen licencia MIT. Así que, me está devolviendo mi root, nodo, y todos los workspaces porque esos no tienen ninguna licencia en absoluto, pero también está recogiendo cualquier cosa que esté usando una licencia diferente a MIT.

Por ejemplo, sé que Prev, Wedge, todos estos están usando la licencia predeterminada ISC de NPM. En este ejemplo, estoy seleccionando paquetes por el nombre del autor. Así que, en este ejemplo, seleccionaría todos los paquetes que dependen de los paquetes de Ruiz. Así que, está combinando algunos selectores más en el mismo lugar. Y puedes ver que estoy usando este nombre, comienza con Ruiz, que es un selector de atributos. Esto me permite seleccionar en propiedades del archivo package JSON de cada dependencia. Así que, básicamente estoy seleccionando por el nombre del autor, comienza con Ruiz, y quiero obtener cualquier paquete que tenga ese paquete que contenga el nombre del autor Ruiz. Así que, mi resultado aquí, como puedes ver en el diagrama, es que el servidor de masterclass contiene una dependencia que fue publicada por un autor llamado Ruiz.

Hay muchos más selectores con los que trabajar y este DSS es cómo hablamos con el gráfico. Si lees los selectores CSS, ya conoces el modelo mental, tenemos alrededor de 60 pseudo selectores que cubren tipo de dependencia, seguridad y más, y selectores de atributos que son solo combinaciones infinitas. Te permite filtrar por nombre, versión, fecha de publicación, autor, licencia, cualquier cosa que puedas imaginar. Ahora, echemos un vistazo a cómo este lenguaje de consulta se integra con otros comandos en el cliente VLT. Comencemos aquí con este pequeño ejemplo, comencemos en la terminal aquí, voy a consultar estrella. Así que, estoy obteniendo los mismos resultados de los diagramas que acabamos de ver, pero aquí está la representación en la línea de comandos de cómo se ve.

Y desde aquí, voy a usar el comando Pkg que me permite agregar nuevas propiedades a los archivos package.json y voy a seguir adelante y agregar la dependencia VTest para cada una de mis masterclasses. Así que, estoy usando el alcance de masterclass aquí para delimitar en qué paquete estoy trabajando y también estoy agregando pruebas de script. Así que, ahora podemos seguir adelante y repetir nuevamente ese alcance de masterclass y vamos a intentar obtener los scripts para ver si llegaron allí.

Sí, y puedes ver que los scripts ahora para cada una de las masterclasses tienen pruebas apuntando a VTest index test. Entonces, ejecutando una instalación de VLT aquí y ahora puedo realmente consultar esa nueva dependencia editada. Así que, puedes ver que VTest ha sido destacado aquí en los resultados para cada una de las masterclasses a las que se añadió.

En este otro ejemplo, comenzaremos listando archivos en mis masterclasses. Así que, puedes ver que el cliente servidor y la masterclass de herramientas tienen solo el archivo package.json dentro de ellas. Y voy a usar VLX para simplemente ejecutar un comando en todas las masterclasses nuevamente. Así que, estoy usando el alcance de masterclass y voy a simplemente tocar ese archivo de prueba para agregar esa prueba a cada una de las masterclasses. Así que, ahora puedo ejecutar nuevamente el mismo comando y puedo listar y ver que esos archivos han sido añadidos. Así que, las masterclasses ahora tienen el archivo index test JS en ellas.

El siguiente ejemplo aquí, voy a ejecutar VLR, que es un atajo para VLT run, y voy a usar el alcance de masterclass nuevamente y ejecutar pruebas. Y puedes ver que ejecuté exitosamente VTest en cada una de las masterclasses. Y este ejemplo final aquí, para solo resaltar el uso de la consulta en este tipo de comandos básicos, voy a usar algo como version. Y voy a básicamente parchear la versión para todas mis masterclasses usando nuevamente el selector de columna de masterclass. Así que, puedes ver que cada una de mis masterclasses ahora ha incrementado su versión a 1.0.1 y tiene un nuevo commit y etiqueta, tal como esperarías.

Desde el comando version. Así que, ahora pasemos a mostrar solo un poco algunas de las características más avanzadas del cliente VLT. Y comencemos con las instalaciones de paquetes por fases. Así que, cada vez que ejecutas una instalación, estás ejecutando código arbitrario de potencialmente miles de paquetes y autores de paquetes. Así que, cuando instalas scripts que se ejecutan automáticamente con acceso completo a tu sistema, antes de que tengas siquiera la oportunidad de revisar lo que se ha instalado, puede ser arriesgado, ¿verdad? Así que, este modelo de confianza por defecto ha sido un punto ciego de seguridad durante años. Y estamos tratando de repensar eso aquí.

Así que, VLT introdujo dos fases distintas. Fase uno, VLT install descarga y extrae paquetes en node modules, pero no se ejecutan scripts de ciclo de vida. Y en la fase dos, VLT construye scripts seleccionados usando la sintaxis del selector de dependencias para el direccionamiento. Esto significa que puedes inspeccionar tu gráfico de dependencias, verificar problemas de seguridad y decidir qué construir antes de que se ejecute cualquier código. Por defecto, todos los scripts de instalación están bloqueados. Así que, aquí hay algunos ejemplos de lo que puedes hacer. Y aquí es donde DSS realmente brilla en la fase de construcción. Puedes dirigir exactamente qué dependencias tienen permitido ejecutar scripts, por nombre, por alcance, o usando cualquier selector DSS.

El valor predeterminado sensato construye todos los paquetes con scripts que aún no se han construido, mientras excluye automáticamente cualquier cosa marcada como malware. Dos nuevos pseudo-selectores, script y build, hacen que la gestión de construcción sea sencilla y componible con el resto del lenguaje. Así que, ejecutemos otro ejemplo aquí. Esta vez, vamos a consultar y veamos qué paquetes no se han construido en este proyecto. Y puedo ver, oh, puedo ver que ES build y FS events no lo han sido. FS event se muestra dos veces, pero es solo un paquete. Así que, puedes ver que cuando ejecuto vote build aquí, dos paquetes se han construido exitosamente. Y ahora cuando ejecuto script not build, no obtengo nada. Y cuando ejecuto vote query scripts build, una vez más, veré los mismos paquetes al principio, pero ahora están construidos.

Consultando múltiples proyectos. Para expandir más la capacidad del lenguaje de consulta DSS, también existe la posibilidad de filtrar paquetes a través de múltiples proyectos utilizando el selector host local. Vamos a echarle un vistazo. Entonces, el host local, cuando prefijas tu consulta con eso, te permite cambiar el contexto de esa consulta para no solo dirigirte al proyecto actual, sino a todos los proyectos configurados en tu sistema. Puedes configurar todos los proyectos, qué carpetas quieres reconocer, carpetas anidadas como proyectos que pueden ser gestionados de esa manera. Así que, el selector host local básicamente expande el lenguaje de consulta a más de un solo proyecto. Y tenemos algunos ejemplos aquí, como, ¿qué pasa si quieres hacerte la pregunta, ¿tengo algún malware? ¿Tengo paquetes que han sido posteriormente documentados como malware instalados en mi máquina? Es posible saberlo ejecutando vote query usando host local malware. ¿Qué pasa si solo quiero cambiar el autor en múltiples proyectos locales? Es posible hacerlo ejecutando vote scope usando el host local. Y estoy apuntando al proyecto raíz porque solo quiero cambiar el package json de mi raíz para poner mi nombre en ellos usando pkg set author name.

Así que, aquí hay otra demostración sobre el uso de host local. Así que, vamos a ejecutar vote query host local aquí y encontrar todos los paquetes que tengo que tienen scripts definidos en ellos. Así que, puedes ver que tengo muchos. Tengo muchos proyectos configurados en este entorno. Así que, voy a seguir adelante. Y por curiosidad, quiero echar un vistazo. Quiero inspeccionar cómo se ven estos scripts. Así que, voy a usar esa misma consulta como un scope aquí y voy a usar pkg pick. Y voy a elegir el nombre para que pueda saber qué paquete estoy mirando. Y voy a seleccionar install, post install, prepare. Así que, puedo ver qué hay realmente en este paquete.

Así que, puedo ver qué hay realmente en estos scripts para cada uno de estos paquetes. Y lo que obtengo es básicamente como una lista con solo ese metadata que fue seleccionado usando pkg pick. Y puedo mirar el código ahora que vamos a ejecutar. Así que, para resumir, una última cosa. Y esto es cada vez más relevante. Los agentes de IA se beneficiarán enormemente de este enfoque. Cuando el gráfico de dependencias es un artefacto consolidado y consultable, los agentes obtienen datos estructurados en lugar de rastrear miles de archivos en tu carpeta node modules. Obtienen salida legible por máquina de cada consulta. Y obtienen seguridad rica, los datos, la relación, todo en una sola fuente. Así que, va a ser menos datos para buscar, menos búsqueda y resultados más rápidos. Quiero recordarles a todos que el gráfico está ahí. VLT solo te está ayudando a trabajar con eso.