¿Qué hay de nuevo en npm?

Bienvenidos a todos. Gracias por unirse hoy. Mi nombre es Darcy Clark y voy a hablar sobre las novedades en la CLI de NPM. Quiero agradecer a todos los que han organizado la conferencia hasta ahora y a todas las personas detrás de escena en DevOpsJS 2021.

Una breve descripción de quién soy. Soy el gerente de ingeniería del equipo de CLI de NPM en GitHub. Estoy basado aquí en Toronto, Ontario, Canadá, y me pueden encontrar en varias plataformas en línea. Así que quiero comenzar hablando un poco sobre lo que hace NPM o lo que la gente piensa que hacemos. Y creo que lo que más se nos conoce es por instalar una gran cantidad de paquetes, esta es nuestra cantidad promedio de descargas de paquetes. Creo que la última vez que verifiqué, estábamos cerca de las 125 mil millones de descargas mensuales como comunidad, lo cual es un logro asombroso. Creo que teníamos alrededor de 100 mil millones de descargas mensuales promedio en septiembre, octubre, octubre, alrededor del 11 aniversario del 11º año de NPM, lo cual es bastante genial. Hacemos más que solo instalar y publicar paquetes. La CLI de NPM también admite descubrimiento, construcción, empaquetado, pruebas y muchas otras funciones con una serie de comandos. Si estás buscando información sobre los más de 61 comandos y en crecimiento, puedes consultar nuestra documentación en docs.npmjs.com. Recientemente, la documentación recibió un nuevo diseño y una actualización, y hay una gran cantidad de información sobre la configuración y los comandos que admitimos. Entonces, ¿qué ha cambiado en la CLI de NPM? Porque es posible que te hayas cambiado de herramienta hace un tiempo. ¿Qué ha cambiado o qué hay de nuevo en la CLI de NPM? Bueno, lo que ha cambiado bastante es nuestro equipo. En los últimos años, hemos agregado y hemos tenido nuevos miembros en nuestro equipo. Actualmente, tenemos un equipo central compuesto por mí, Roy Adorno, Nathan Lafreniere y Michael Garvan, nuestro GAR. También estamos expandiendo este equipo y agregando tres nuevos miembros el próximo mes. También recibimos una gran cantidad de colaboradores, casi 700 colaboradores en la CLI de NPM, lo cual es bastante asombroso. Lo que también ha cambiado es que recientemente lanzamos NPMv7 y se hizo disponible en enero de 2021. En la versión 7, introdujimos muchas nuevas capacidades, incluidas algunas mejoras en los comandos heredados y también agregamos cosas como el soporte para espacios de trabajo, entre muchas otras cosas más. Así que profundicemos en algunos de estos cambios.

En la versión 7, una de las cosas más importantes que notarás es que hemos comenzado a instalar las dependencias entre pares de forma predeterminada. Las dependencias entre pares no son nuevas en absoluto, han estado presentes durante unos ocho años. Pero lo que notamos es que muchos proyectos tenían que y muchos desarrolladores tenían que gestionar manualmente estas dependencias, lo cual es un problema. NPM es un administrador de paquetes y queremos gestionar tus paquetes. En este ejemplo, puedes ver que tengo dos proyectos de espacios de trabajo que dependen de diferentes versiones de React. Estas versiones son conflictivas y nosotros

no sabemos exactamente qué... Anteriormente, simplemente dejábamos esto y permitíamos que los desarrolladores los gestionaran. En la versión 7, ahora haremos todo lo posible para instalar y resolver tus dependencias entre pares. Y si no podemos, mostraremos una especie de advertencia con algunos pasos accionables para que resuelvas estas dependencias. Y si estás buscando la lógica real que se ejecuta y realiza esta resolución, hemos trasladado todo lo que... Es decir, el cerebro de las operaciones, a un nuevo paquete que llamamos Arborist. Continuando, también hemos introducido, para ayudar con este cambio, npm explain, o el alias npmy. Y este comando funciona de manera similar a npmy y npm explain de yarn, donde te mostrará la razón por la que se instaló un paquete. En este caso, he ejecutado npm explain chalk, preguntando esencialmente por qué está instalado chalk, y npm te informará que en este caso, tengo un proyecto de espacio de trabajo llamado b, y en realidad incluye chalk como una dependencia entre pares, y esa es la razón por la que se instaló. Así que tenemos una buena experiencia para los desarrolladores y herramientas para ayudar con la ergonomía en la gestión de tus dependencias.

Además, lo nuevo en npm exec se introdujo en la versión 7. Es esencialmente el núcleo de npx. Entonces, si alguna vez has usado npx, esto no será algo nuevo para ti. Hemos agregado algunas salvaguardias con npm exec y npx. En la versión 7, ahora pedimos confirmación antes de instalar un paquete que nunca hemos visto antes, te pedimos que confirmes y tenemos un mensaje de confirmación para asegurarnos de que no instales accidentalmente algo y ejecutes algo que no querías hacer. También a partir de la versión 7, hemos realizado cambios significativos en npm audit. npm audit ha sido refactorizado en términos de lógica, rendimiento y también interfaz de usuario. Ahora esperamos que sea mucho más fácil para los desarrolladores comprender rápidamente qué está sucediendo y cuáles son las banderas para las diferentes dependencias que pueden tener un problema de vulnerabilidad. Y esperamos que esta sea una experiencia mucho más rápida para los desarrolladores y que sea una experiencia mejorada en general. Y un nuevo comando que hemos introducido recientemente es npm diff. Con npm diff, funciona de manera similar a git diff, donde puedes especificar un nombre de paquete, una versión o un archivo y puedes ver la diferencia entre esas dos cosas. Esto es genial. En este ejemplo, estoy viendo los cambios entre dos versiones diferentes de mi paquete llamado sleepover y puedo ver que la versión se actualizó y el archivo package.json cambió ligeramente. Otro gran cambio en npm v7 fue la introducción de un nuevo esquema de bloqueo de paquetes. Anteriormente estábamos en la versión 1 del bloqueo de paquetes y al hacer la transición o al actualizar a npm v7, actualizaremos automáticamente la versión de tu archivo de bloqueo de paquetes para cumplir con este nuevo esquema. Por lo tanto, no debería haber problemas con la actualización y si tienes algún problema con los desarrolladores que usan v6 o v7, puedes decir no guardar o proporcionar la bandera no guardar para no actualizar tus archivos de bloqueo de paquetes. Otro gran logro que hemos logrado con npm v7 son algunas mejoras en el rendimiento real de muchos de los comandos. Específicamente en la instalación, inicialmente vimos una especie de degradación, pero notamos que en realidad estábamos instalando más dependencias debido a los cambios en el comportamiento que habíamos introducido con las dependencias entre pares. Por lo tanto, la resolución de dependencias entre pares aumentó nuestros tiempos de instalación porque en realidad estábamos instalando y resolviendo más dependencias, por lo que esto era algo esperado, y como puedes ver hemos comenzado a realizar pruebas de referencia en diferentes escenarios y configuraciones, incluida la instalación de dependencias entre pares. Esa es la última prueba de referencia en la parte inferior. A medida que avanzamos, vimos que hemos logrado mejoras significativas en comparación con nosotros mismos y esperamos continuar este trabajo dentro de las suites de pruebas de referencia que estamos ejecutando y esperamos seguir enfocándonos en el rendimiento como un área para nosotros

para optimizar y mejorar. Si alguna vez estás interesado en el trabajo que estamos haciendo allí, puedes ir a npm slash benchmarks y ver las diferentes ejecuciones que estamos realizando con las diferentes versiones de npm que estamos construyendo.

Entonces, npm v7 introdujo soporte para espacios de trabajo. Esto fue una gran victoria para nuestro equipo. Es algo que queríamos ofrecer a la comunidad de desarrolladores desde hace tiempo. El soporte básico aquí para los espacios de trabajo es simplemente la definición de los proyectos dentro de tu proyecto principal.

En este caso, en este ejemplo, simplemente he definido un espacio de trabajo A y B. Y a partir de la versión 7, 7.0.0, el único comando real que entendía o soportaba estas definiciones de espacios de trabajo era npm install. Y en realidad tengo una referencia a nuestra documentación. Y también hay referencias al RFC que creamos originalmente para este soporte básico.

Desde entonces, hemos dividido el trabajo en otras dos fases. Y la segunda de ellas es en lo que hemos estado trabajando recientemente, que es hacer que más comandos sean conscientes de los espacios de trabajo. Y esta segunda etapa de trabajo realmente abarca los otros 60 comandos que tenemos para definirlos y categorizarlos en términos de su conciencia de espacios de trabajo.

Lo que verás son dos nuevas configuraciones que se lanzarán en la próxima semana, junto con otros trabajos asociados a la conciencia de espacios de trabajo. La primera configuración que tenemos es 'workspaces'. Es esencialmente un booleano que se pasa a cualquiera de los comandos de NPM para indicarte que deseas ejecutar ese comando en los espacios de trabajo que has definido. Y luego la segunda configuración es una especie de comando filtrado para el espacio de trabajo específico en el que deseas ejecutar el comando. Así que eso es 'workspaces' y 'workspace'. Por lo tanto, ws y w son los alias.

Y si vemos cómo se ve esto en la práctica, a partir de NPM 7.7, podrás ejecutar cualquier script o comando del ciclo de vida, como scripts de ejecución, ejecutar pruebas, iniciar, detener, reiniciar con las banderas ws o w. En este caso, he ejecutado las pruebas con ws, y se ejecutan todos los scripts de prueba que están en los espacios de trabajo que he definido en mi proyecto. Y aquí, en este caso, en este ejemplo, he filtrado para ejecutar solo las pruebas del espacio de trabajo A que he definido en este proyecto. Y el espacio de trabajo es muy flexible. Puedes definir el espacio de trabajo varias veces. Así que, en este caso, he definido B y luego A. Y debido a la forma en que está implementado, se ejecutan en serie. Y puedes ver que las pruebas de B se ejecutan primero y luego las de A. Y si definiera más y más espacios de trabajo, verías que se realizan más y más ejecuciones. Por lo tanto, esta nueva función, esta nueva capacidad de trabajar con espacios de trabajo está disponible a partir de NPM v7.7, que lanzaremos en los próximos días. La versión 7.8 tendrá soporte para exec e init, y el resto de los subcomandos que sean conscientes de los espacios de trabajo vendrán posteriormente. Si alguna vez deseas obtener más información

En la última versión de NPM, puedes instalarnos con npm -g. Ahora enviamos semanalmente. Verás nuevos parches, nuevos mineros, nuevas mejoras cada semana. Quiero tomarme un tiempo no solo para hablar de lo que hemos estado enviando y de lo que vamos a enviar, sino también de cómo se ve nuestro pipeline, qué está por venir.

En los próximos trimestres, el segundo y tercer trimestre de 2020, estamos considerando el protocolo de registro y las anulaciones de paquetes como dos RFC que tenemos en mente y que queremos poner en marcha, incluyendo las indicaciones publicadas en el tercer trimestre, que es otro RFC que ha sido aprobado y solo necesitamos hacer el trabajo. Como se mencionó anteriormente, estamos trabajando en mejoras de los espacios de trabajo en este momento y esperamos terminar el trimestre también con instalaciones filtradas o con alcance, lo cual es una característica realmente genial. Si quieres obtener más información sobre el protocolo de registro o las especificaciones de anulación y los RFC que se están proponiendo en este momento, puedes ir al foro npm-RFCs y ver cómo se ven. Y si quieres involucrarte aún más, nuevamente realizamos una llamada semanal npm-OpenRFC, que se lleva a cabo los miércoles a las 2 p.m. hora del este, y es una llamada en vivo donde hablamos sobre el futuro, el presente y el futuro del proyecto y discutimos esencialmente las solicitudes futuras y las cosas que nos gustaría hacer. También tenemos recursos para la documentación a la que hice referencia anteriormente, nuestro rastreador de errores, eventos en los que estamos, en los que estaremos o en los que hablaremos, nuestra hoja de ruta y otros recursos de retroalimentación en npm.community.

Y eso es todo por hoy. Solo quería agradecer a todos los que han estado involucrados en el evento y no dudes en comunicarte en uno de estos enlaces que se encuentran a continuación. ¡Saludos!

¡Hola, qué bueno verte! Vamos a ver los resultados de tu pregunta. ¿Has utilizado anteriormente el npm-cli? Y el 100% dice que sí, wow, parece que es un proyecto popular entonces. Bueno, estás haciendo cosas geniales entonces, supongo. Sí, creo que ayuda un poco que vengamos por defecto con Node y que la mayoría de los desarrolladores esperemos disfruten del trabajo que estamos haciendo. Sí, genial verte. Así que vamos a responder algunas preguntas, si estás dispuesto. Si quieres seguir haciendo preguntas, aún puedes hacerlo en el canal de Discord, por supuesto. Tenemos una pregunta de Ricardo. Él dice tres cosas, en realidad. Dice, ¿Boris es un árbol de sacudidas? Muy bien encontrado. ¿O gestionando el árbol de dependencias? Quiero decir, wow, los espacios de trabajo son una gran ventaja. Esa siempre fue la razón para usar Yarn en lugar de NPM. Ya no más. ¡Yay! Así que él está muy contento con los espacios de trabajo. Sí, estamos bastante emocionados de proporcionar eso para la comunidad. Queremos tener una experiencia de espacio de trabajo de primera clase. Así que sí, estamos bastante emocionados de completar y tener más características dedicadas a ese tipo de casos de uso para las personas que tienen proyectos de mono repositorio. Sí. Genial. Sb, estás haciendo una pregunta a Thomas, pero creo que te refieres a Darcy, porque él está preguntando, ¿cuáles son los planes para npm v6? Así que para npm v6, en el pasado hemos hecho, con las principales versiones, que el equipo del cliente de npm ha brindado soporte para actualizaciones de seguridad a versiones anteriores importantes. Por ahora, el plan es seguir manteniendo npm v6, en términos de cualquier parche de seguridad que necesitemos aplicar a eso. La esperanza es mantenerlo hasta que la última versión LTS de Node que depende de él llegue al final de su vida útil. Esto significa que lo estaremos respaldando por un tiempo y trataremos de mantenernos al tanto, si se presentan CVE contra las dependencias de v6, haremos todo lo posible para estar al tanto de ellos. Pero la idea es que, ya sabes, v6 está prácticamente completo en cuanto a características, y esperamos que la gente actualice a v7 y obtenga muchos beneficios al hacer eso, incluyendo, ya sabes, mejoras de rendimiento. Y ahora v7 es simplemente una base de código mucho mejor. Así que sí, esperamos que la gente se sume y sí. Genial. Y lo que me intriga es, como mantenedor de este gran proyecto, ¿lo usas tú mismo? ¿Solo lo mantienes, o también lo usas para tus proyectos personales los fines de semana? ¿O cómo te mantienes actualizado siendo un usuario? Uso varias herramientas diferentes en muchos proyectos diferentes, pero definitivamente

Actualmente uso v7 para todo lo que hago con proyectos de NPM. Así que sí, definitivamente soy un consumidor frecuente. Y como v7 se está enviando actualmente en Node 15, y me gusta estar en la última y mejor versión de Node, es realmente fácil mantenerme actualizado. Uso NPM como administrador de versiones de Node. Por lo tanto, es fácil para mí usar en mis proyectos la última versión de NPM v7 también. No tengo muchos proyectos de monorepo, por lo que no he estado utilizando los espacios de trabajo tan intensamente, pero estamos comenzando a usar específicamente los espacios de trabajo y hemos agregado muchas utilidades interesantes en v7. Por ejemplo, NPM diff es algo que he comenzado a usar casi todos los días, especialmente para los registros de cambios. Es una herramienta muy útil para poder comparar entre tu última versión. Y especialmente para los registros de cambios, es fácil extraer esa información de esos archivos. Y sí, he estado utilizando, ya sabes, la instalación automática de dependencias de pares, lo cual también es algo en lo que realmente confío ahora, y no tengo que administrar manualmente las dependencias de pares en mis proyectos, lo cual es agradable. Así que sí, lo uso todos los días. Definitivamente soy un consumidor del proyecto. Genial. Sí, es bueno escuchar eso. ¿Puedes contarnos un poco sobre, sé que has estado trabajando en NPM incluso antes de que fuera adquirido por GitHub. ¿Puedes contarnos un poco sobre tu historia allí y cómo fue la adquisición por parte de GitHub y lo que puedas compartir, por supuesto? Puedo contarte un poco. En realidad, ha sido una adquisición muy buena para nosotros. Creemos que NPM ha encontrado un buen hogar con GitHub y también con la organización de Microsoft. Me uní al equipo de NPM Inc. aproximadamente 10 meses antes de que fuéramos adquiridos y estábamos trabajando bastante duro para actualizar y modernizar diferentes áreas de la empresa. Creo que eso también fue bastante atractivo para GitHub. Creo que vieron una buena combinación allí. Creo que era evidente que estas dos organizaciones deberían ser una. Sí, ha sido realmente emocionante, entre bastidores, comenzar a colaborar con GitHub y también ver cómo se ve el futuro de la hoja de ruta para las características que podemos ofrecer a la comunidad basándonos en esta estrecha colaboración. Así que hay muchas cosas en proceso de las que no puedo hablar en este momento, pero debería haber algunas noticias en otoño sobre muchas cosas que estamos haciendo con NPM y GitHub. Y

obviamente, la CLI seguirá mejorando. Y eso también ha sido una gran victoria para nosotros. Nuestro equipo ha crecido y definitivamente podemos apoyar y mantener los proyectos de la CLI en el futuro aquí por mucho tiempo. Genial. Genial. Vamos a desviarnos un poco. ¿Cuál es tu abreviatura de chiste favorita de NPM? ¿Chiste favorito? Sí. Entonces, en el sitio web, nunca dices Node Package Manager, ¿verdad? Dices NPM y luego siempre es algo diferente. ¿Cuál es tu favorito? Sí. Creo que uno de ellos es Ninja Pizza Monsters. Creo que es una referencia a las Tortugas Ninja Mutantes Adolescentes. Creo que ese es uno de los que he visto. Sé que hay miles de ellos. Esa lista vive en algún lugar de GitHub y la gente ha ido agregando a lo largo de los años. Y es una lista bastante larga de abreviaturas.

Sí. Sé que puedes enviar una solicitud de extracción. Y una vez he navegado por esa lista, y es realmente interminable y muy divertida. Siempre me gusta cuando las empresas, bueno, especialmente las grandes empresas, tienen este tipo de chistes y no se toman demasiado en serio. Es divertido ver eso. Sí, es bastante interesante. Mucha gente no sabe que NPM no es un acrónimo de Node Package Manager. Así que ahora tenemos una definición adecuada en el README, solo para que la gente lo sepa. Es una historia realmente interesante allí, y dejaré que la gente vaya a leer la historia del nombre real de NPM. Está ahí en el README de la CLI. Ahora estás tratando de generar más tráfico. Te estás robando todo nuestro tráfico. Espero que tu servidor esté listo. Creo que nos hemos quedado sin preguntas. Así que si alguien quiere hacerle más preguntas a Darcy, Darcy estará disponible en Discord. No está disponible en spatial chat. Darcy, muchas gracias por unirte a nosotros y espero verte de nuevo pronto y tal vez en persona. Eso sería increíble. Muchas gracias. Adiós. Adiós. Adiós. Adiós.