¡Hola a todos! Estoy seguro de que has visto usando diferentes administradores de paquetes, es decir: proyectos de Node.js (el predeterminado) npm hilo pnpm Lo he visto yo mismo y he trabajado con todo lo anterior, pero siempre tuve una pregunta en mente: ¿qué impulsa a las personas/equipos a usar o en lugar de ? ¿Cuáles son las ventajas? ¿Hay alguna desventaja? hilo pnpm npm Bueno… ¡descubrámoslo! Reglas de comparación de desempeño Decidí comparar , y en términos de su "velocidad"... npm Yarn pnpm Verás 3 medidas a continuación: Genere un archivo de bloqueo sin caché. Instale dependencias de archivos de bloqueo existentes sin ningún caché. Instale dependencias de archivos de bloqueo existentes con caché global. Hay dos tipos de caché: Global. Generalmente se almacena en el directorio de inicio del usuario (por ejemplo, ). ~/.yarn/berry/cache Local. Almacenado en el directorio del proyecto (fe, ). <project-dir>/.yarn Si bien los casos de uso y son los casos de uso más comunes en mi experiencia, también tomé por si acaso (aunque es un caso muy raro). 2 3 el n.° 1 Utilicé un proyecto de muestra de como ejemplo para los puntos de referencia. create-react-app npm Es un administrador de paquetes predeterminado para el ecosistema ¿Qué más decir? Viene con el paquete de instalación, por lo que básicamente está listo para usar cuando instala en su máquina (o en cualquier proveedor si configura allí). Node.js. Node.js de CI Node.js En mi opinión, eso es una gran “ventaja”: ¡no es necesario instalarlo por separado! No hay nada extraordinario allí, simplemente... ¡funciona! Y no he visto ningún error importante a lo largo de los años: parece bastante estable y hace el trabajo. Las características de que usé hasta ahora: npm Administrar dependencias (instalar, eliminar, actualizar) Publicar paquetes (privados, públicos) Paquetes de enlace local Administrar espacios de trabajo. Administrar dependencias almacena las dependencias en la carpeta de la raíz de su proyecto. Muy claro. npm node_modules ℹ️ almacena información sobre los registros de los paquetes enumerados; resulta útil si tiene paquetes de un solo ámbito, es decir, en diferentes registros (por ejemplo, paquetes y ): package-lock.json MUY @example-company npm GitHub Ahora, veamos cómo se comporta en términos de velocidad de instalación… Generar package-lock.json sin caché Tomó para que genere un e instale dependencias sin ningún caché. 1 minuto npm package-lock.json Comando utilizado: npm i Instale dependencias desde package-lock.json sin ningún caché Tomó para que instale dependencias desde sin ningún caché. 18 segundos npm package-lock.json Comando utilizado: npm ci Instalar dependencias desde package-lock.json con caché global Tomó para que instale dependencias desde con caché global. 8 segundos npm package-lock.json Comando utilizado: npm ci Administrar espacios de trabajo Pude crear y administrar dependencias para todo el espacio de trabajo a la vez y para proyectos específicos por separado. un espacio de trabajo En otras palabras, hace el trabajo sin errores ni problemas, y la documentación oficial es bastante sencilla. Funciones del espacio de trabajo que utilicé hasta ahora: Instale dependencias para todos los proyectos dentro del espacio de trabajo. Instalar dependencias para un único proyecto específico. Ejecute un único script para todos los proyectos a la vez de forma recursiva. hilo Sinceramente, no he probado mucho algunas de las funciones . Quiero decir, lo usé mucho en términos de "instalar dependencias" mientras trabajaba en algunos proyectos, y eso es todo. del hilo no viene con un instalador , por lo que tendrás que instalarlo por separado. Significa que habría un paso adicional en sus canalizaciones : tendría que configurar antes de instalar las dependencias de su proyecto. Yarn de Node.js de CI hilo Administrar dependencias tiene dos enfoques para instalar dependencias: Yarn “ ” (predeterminado): crea una carpeta y enumera los paquetes en archivos y . Instalaciones cero .yarn yarn.lock .pnp.cjs Uno normal, similar a , almacena las dependencias en y las enumera en el archivo . npm node_modules yarn.lock ℹ️ Los archivos de bloqueo almacenan información sobre los registros de todos los paquetes enumerados si utiliza el método de instalación antiguo (normal). de hilo SÓLO ⚠️ Tenga en cuenta que " " parece almacenar paquetes en el caché local y proporcionar enlaces a sus archivos de bloqueo: Zero Installs Puede ser importante para usted si tiene una canalización o donde instala dependencias en un entorno limpio y luego desea moverlas a otro (deberá copiar tanto la carpeta como el caché local). Dockerfile CI .yarn Dado que el enfoque predeterminado para hilo ahora es " " y tiene mejor rendimiento que el enfoque anterior, registraremos puntos de referencia solo con este enfoque. Instalaciones cero Generar archivos de bloqueo sin caché Tomó para que genere un archivo e instale dependencias sin caché. 16,5 segundos Yarn yarn.lock Comando utilizado: yarn install Instalar dependencias de archivos de bloqueo existentes sin ningún caché Tomó para que instale dependencias con el enfoque de “Instalación cero” y sin ningún caché. 11 segundos Yarn Comando utilizado: yarn install --frozen-lockfile Instalar dependencias de archivos de bloqueo existentes con caché global Tomó para que instale dependencias con el enfoque de “Instalación cero” y caché global. 8 segundos Yarn Comando utilizado: yarn install --frozen-lockfile Administrar espacios de trabajo Pude crear y administrar dependencias para todos los proyectos a la vez y para proyectos específicos por separado. un espacio de trabajo Funciones del espacio de trabajo que utilicé hasta ahora: Instale dependencias para todos los proyectos dentro del espacio de trabajo. Instalar dependencias para un único proyecto específico. Ejecute un único script para todos los proyectos a la vez de forma recursiva. La documentación está bien, pero los nombres de los comandos y las banderas son algo confusos. Por ejemplo, debo ejecutar esto para ejecutar el script en ( ) y el proyecto anidado: test la raíz . b2b yarn workspaces foreach -A --include '{.,b2b}' run test En comparación con : npm npm run test --workspace=b2b --include-workspace-root pnpm actualmente está de moda: . pnpm muchas empresas y proyectos de código abierto lo utilizan Al igual que , no viene con un instalador , por lo que deberá instalarlo por separado. Significa que habrá un paso adicional en sus canalizaciones : tendrá que configurar antes de instalar las dependencias de su proyecto. Yarn pnpm de Node.js de CI pnpm Administrar dependencias se considera un ... pnpm " " administrador de paquetes rápido y eficiente en el espacio en disco De hecho, estoy de acuerdo con la afirmación de en términos de gestión de dependencias localmente. "eficiente espacio en disco" De forma predeterminada, elimina las duplicaciones de las dependencias compartidas. crea enlaces simbólicos para los paquetes que se utilizan en múltiples dependencias. es decir, si los paquetes y usan el paquete como dependencia, almacenará el paquete como una copia única y creará enlaces simbólicos para los paquetes y . De esa manera, el administrador de paquetes no crea copias impresas y ahorra memoria en su SSD/HDD. pnpm pnpm a b c pnpm c a b ℹ️ no almacena información sobre los registros de los paquetes enumerados. pnpm-lock.yaml ⚠️ Tenga en cuenta que a veces almacena dependencias en la caché global, en lugar de mantenerlo como proyecto. pnpm Genere pnpm-lock.yaml sin ningún caché Tomó para que genere un e instale dependencias sin ningún caché. 31 segundos pnpm pnpm-lock.yaml Comando utilizado: pnpm install Instalar dependencias desde pnpm-lock.yaml sin caché global Tomó para que instale dependencias desde sin caché. 16 segundos pnpm pnpm-lock.yaml Comando utilizado: pnpm i --frozen-lockfile Instalar dependencias del archivo de bloqueo existente con caché global Tomó para que instale dependencias desde con caché global. 5 segundos pnpm pnpm-lock.yaml Comando utilizado: pnpm i --frozen-lockfile Administrar espacios de trabajo Ahora, ahí es donde las cosas se vuelven realmente interesantes... tiene muchas opciones de configuración, ¡pero algunas funciones principales simplemente no funcionan! pnpm Repasemos un par de errores que enfrenté: instalación pnpm --filtro Es importante poder instalar dependencias solo para proyectos específicos; es bastante útil para monorepos cuando crea canalizaciones relacionadas con proyectos específicos dentro del espacio de trabajo. es decir, imagina que tienes en tu espacio de trabajo: una aplicación web, servidor de fondo, proyecto de prueba (pruebas de extremo a extremo). Todos estos son proyectos separados, pero son parte del mismo repositorio ☝️ npm Ahora desea que una canalización ejecute pruebas de un extremo a otro únicamente. Entonces, solo necesitas dependencias de prueba de un extremo a otro, ¿verdad? Bueno, no podrás hacer eso: te obliga a instalar dependencias para todo el espacio de trabajo! ¡pnpm Se suponía que instalaría dependencias solo para proyectos seleccionados, pero no funciona. pnpm install --filter <project-name> Hay un error de hace un año y recientemente se cerró con una solución que no funciona. instalación recursiva = falso instala de forma predeterminada dependencias para todo el espacio de trabajo (todos los proyectos) cuando ejecuta pnpm pnpm install Puede alternar este comportamiento si configura en en la raíz de su espacio de trabajo. recursive-install=false .npmrc PERO . introduce otro error que ya tiene casi 2 años espacio de trabajo compartido-lockfile=false almacena de forma predeterminada la lista de dependencias en un único archivo de bloqueo (igual que y ). pnpm npm Yarn También puede alternar este comportamiento si configura en en la raíz de su espacio de trabajo. shared-workspace-lockfile=false .npmrc Eso nos permitiría mantener la función del espacio de trabajo y usar el indicador para instalar dependencias para un proyecto específico. --ignore-workspace De todos modos, esta configuración introduce un par de problemas más: y arrojan un error en mis canalizaciones . eslint tsc --noEmit "JavaScript sin memoria" de GitHub Actions Algunas de las dependencias se almacenan en la caché global y tienen enlaces simbólicos en . node_modules/.pnpm Resultados de la comparación de rendimiento # npm hilo pnpm Generar un archivo de bloqueo 60 seg 16,5 segundos 31 seg Instalar dependencias sin caché 18 seg 11 seg 8 seg Instalar dependencias con caché global 8 seg 8 seg 5 segundos Según el punto de referencia anterior, es el administrador de paquetes más lento ☝️ npm De todos modos, interpretemos estos resultados… Generar un archivo de bloqueo Es un caso raro. Por lo general, se crea un archivo de bloqueo al inicializar el proyecto y luego se expande cuando instala/actualiza paquetes. Teniendo esto en cuenta, no parece algo muy importante en lo que confiar al elegir un administrador de paquetes. Instalar dependencias En la mayoría de los casos, sus proyectos mantienen una lista específica de dependencias y rara vez agrega o elimina algo. Lo más probable es que cambies las versiones de tus paquetes de vez en cuando; estos cambios son pequeños y reutilizarás el resto de los paquetes del caché. En otras palabras, el caso de uso común es: buscar nuevos paquetes del registro de paquetes y tomar el resto del caché. (5-8 segundos) es casi el doble de rápido que (8-18 segundos) con (8-11 segundos) en el medio. pnpm npm hilo Conclusión Hechos es de hecho ; ¡está bastante claro en la revisión actual! pnpm un administrador de paquetes “rápido y eficiente en disco” La característica del espacio de trabajo tiene errores y algunos de los errores no se han resuelto durante años. pnpm Tanto como requieren una configuración adicional en las canalizaciones de CI, mientras que no. pnpm Yarn npm Tanto como no almacenan información de registro de paquetes en sus archivos de bloqueo, mientras que sí. pnpm Yarn npm Pensamientos del autor Creo que hace el mejor trabajo si su requisito para el administrador de paquetes es tan simple como "instalar solo dependencias". pnpm Aunque no viene con un instalador de listo para usar, es fácil de configurar en canalizaciones de CI con o . pnpm Node.js corepack action existente Prefiero porque: npm es estable (especialmente espacios de trabajo), viene con y no requiere una configuración adicional en el proceso de CI, Node.js almacena registros de paquetes en para que pueda instalar dependencias con un único alcance desde diferentes registros. package-lock.json Estas ventajas superan los segundos de velocidad y espacio en disco que ahorraría con o . hilo pnpm ¿Cuáles son sus criterios para elegir un administrador de paquetes? ¡No seas tímido y déjame saber tu opinión en la sección de comentarios a continuación! 👇😊
