Estoy haciendo que las dependencias de enlace tarden más de 200 segundos con este https://github.com/macdja38/pvpsite/blob/master/package.json en Windows 10, en un SSD con un i7 decente.

Parece que el problema de rendimiento puede ser causado por Windows Defender, deshabilitándolo mientras posiblemente no sea aconsejable reducir 200s a un lugar más cercano a 50.

Creo que debería haber una solución mejor que reducir la seguridad.

Algunos otros usuarios han confirmado que deshabilitarlo solo en el directorio raíz de su proyecto funciona, pero no puedo confirmarlo, ya que Windows Defender se rompió un poco cuando intenté hacer eso.

Tengo el mismo problema con el repositorio de git con aproximadamente 30 dependencias.
Windows 10
nodo v5.5.0
hilo 0.16.1

La desactivación de Windows Defender redujo significativamente el tiempo de vinculación

¿Probablemente debería ser "resuelto" por este PR ?

Sí, desafortunadamente, no hay mucho que podamos hacer aquí :( Los escáneres de virus analizan todos los archivos, y el ecosistema npm tiene muchos archivos pequeños. Los archivos pequeños generalmente tienen un poco más de sobrecarga en NTFS en comparación con otros sistemas de archivos como EXT4 o ZFS, pero se ve agravado por los escáneres de virus.

Dicho esto, Yarn debería _todavía_ ser más rápido que npm, simplemente no será tan rápido como en Linux o Mac.

Estoy en una Mac sin tener ningún antivirus instalado. Pero sigo viendo el mismo problema, la vinculación lleva una cantidad considerable de tiempo incluso con una aplicación simple de angular-js.

Yo también tengo este problema. Tomó 174 segundos en Ubuntu.

Comencé a tener este problema solo después de actualizar de 0.17.8 a 0.17.19 . Mac sin antivirus.

Lo extraño también es que necesito lanzar el proceso de vinculación cada vez que elimino un paquete. Npm lo hace más rápido. Y vincular realmente lleva mucho tiempo.

Esto se puede reproducir con este package.json (en Heroku):

{
  "name": "yarn-link-slowness",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.15.3",
    "lodash": "^4.17.2",
    "react": "^15.4.1",
    "react-dom": "^15.4.1",
    "react-player": "^0.12.1",
    "react-redux": "^4.4.6",
    "react-router": "^3.0.0",
    "react-router-redux": "^4.0.7",
    "react-scripts": "^0.8.4",
    "redux": "^3.6.0",
    "redux-auth-wrapper": "^0.9.0",
    "redux-logger": "^2.7.4",
    "redux-promise-middleware": "^4.2.0",
    "redux-thunk": "^2.1.0"
  },
  "engines": {
    "node": "7.2.1",
    "yarn": "0.17.8"
  }
}

Con hilo 0.17.8, la instalación tarda 37 segundos. Con hilo 0.17.10, la instalación toma 97 segundos. No hay otros cambios (nuevas aplicaciones de Heroku cada vez).

✨ Hecho en 45.10s.

    "autoprefixer": "6.3.6",
    "babel-core": "6.7.6",
    "babel-jest": "13.0.0",
    "babel-loader": "6.2.4",
    "babel-plugin-transform-class-properties": "6.9.1",
    "babel-plugin-transform-object-rest-spread": "6.8.0",
    "babel-preset-es2015": "6.6.0",
    "babel-preset-react": "6.5.0",
    "bluebird": "3.3.5",
    "cardmask": "github:aj0strow/cardmask#v1.0.0",
    "chai": "3.5.0",
    "classnames": "2.2.5",
    "copy-webpack-plugin": "2.1.3",
    "core-js": "2.4.1",
    "css-loader": "0.23.1",
    "enzyme": "2.3.0",
    "file-loader": "0.8.5",
    "force-case-sensitivity-webpack-plugin": "0.1.1",
    "jest": "13.0.0",
    "jest-cli": "13.0.0",
    "json-loader": "0.5.4",
    "lodash": "4.11.1",
    "moment": "2.13.0",
    "ms": "0.7.1",
    "node-sass": "3.4.2",
    "postcss-loader": "0.9.1",
    "raw-loader": "0.5.1",
    "react": "15.2.0",
    "react-addons-css-transition-group": "15.2.0",
    "react-addons-test-utils": "15.2.0",
    "react-css-transition-replace": "2.0.1",
    "react-dom": "15.0.1",
    "react-redux": "4.4.5",
    "react-router": "2.3.0",
    "react-textarea-autosize": "4.0.3",
    "recompose": "0.20.2",
    "redux": "3.5.1",
    "redux-actions": "0.10.0",
    "redux-thunk": "2.0.1",
    "reselect": "2.5.3",
    "sass-loader": "3.2.0",
    "sinon": "1.17.4",
    "style-loader": "0.13.1",
    "webpack": "1.13.0",
    "webpack-dev-server": "1.14.1",
    "whatwg-fetch": "1.0.0",
    "zxcvbn": "4.3.0"

Por favor, ¿alguien puede explicar qué hace exactamente el hilo en el paso "Vincular dependencias"?
Debido a que el número máximo en este paso varía de ~ 1000 a ~ 65000 para el mismo proyecto en diferentes máquinas. ¿Qué significa este número?

Tener este problema también. Agregar una dependencia con yarn add parece desencadenar "Vincular dependencias" y lleva una eternidad. Tuve que volver a cambiar a npm por ahora.

nodo: 6.9.2
SO: Windows 10

nodo: 7.3.0
SO: Windows 10 64
Lo mismo para mi

Igual que aquí. Enlaces 23420 ... algo, y tarda aproximadamente un minuto y medio en un buen día.

Hilado 0.19.1
NodeJS 7.3.0
Windows 10

yarn add moment tarda 105 segundos. No tiene dependencias. : /

EDITAR: Desactivar Windows Defender reduce el tiempo de ~ 30 a ~ 50 segundos. Intenté excluir el directorio en el que estoy trabajando, pero eso no pareció ayudar.

Acabo de ejecutar una copia nueva de create-react-app y tomó 876.37s. Entiendo que no tienes mucho o ningún control sobre cómo funciona el antivirus, pero mi experiencia con NPM y CRA fue mucho más rápida en Windows.

En Windows 10, simplemente use Ubuntu bash shell como consejo general.

En Windows 10, simplemente use Ubuntu bash shell como consejo general.

La E / S de disco es extremadamente lenta en el subsistema de Windows para Linux, es una limitación conocida en este momento

pero mi experiencia con NPM y CRA fue mucho más rápida en Windows.

@JeffBaumgardt - Interesante ... Yarn es más lento en Windows, ¡pero debería ser más rápido que npm!

@ Daniel15 probablemente debería serlo, pero no lo es. Las instalaciones y desinstalaciones de nodos fueron más pequeñas para mí. Entonces haría npm add <packages> --save-dev , eliminaría yarn.lock y ejecutaría yarn y eso sería más rápido que ejecutar yarn add <packages> -D una sola vez. Ahora que todo el mundo está en lana, por supuesto que no quiero eliminar el candado y obligar a todos a actualizar su paquete. En cambio, lo siguiente ha sido genial:

cc @echobnet

Para cualquier persona con Windows 10 + Windows Defender

1. Configuración del primer clic

   

2. Desplácese hacia abajo hasta las exclusiones

   

3. Ejecute yarn cache dir para obtener la ubicación de su carpeta de caché

   • Agregue esta carpeta de caché a la lista de exclusión
   • Agregue la carpeta node_modules de su proyecto a la lista de exclusión

4. Aceleración para un proyecto de reacción x 3-10

@SleeplessByte o simplemente puede agregar yarn y node a los procesos excluidos.

No es solo un problema en Windows. He estado viendo tiempos de enlace horribles en mi Mac Pro.

SO: OS X 10.11.6 (El Capitan)
Nodo: 7.6.0
Hilado: 0.20.3

Puedo confirmar que también es _muy_ lento en Mac 10.12.3. No relacionado con Windows.

Y parece que mi configuración es _way_ más lenta que otras en este hilo. Yarn a veces intenta vincular alrededor de 600.000 archivos en proyectos pequeños. Esto puede tardar más de 30 minutos. Actualmente lo intento con un caché limpio y todas las noches (v0.22.0-20170226.1626). Utilizo el registro oficial, así como un registro privado personalizado para ciertos paquetes específicos. Sin embargo, mis colegas no sufren este problema, por lo que no creo que el registro privado personalizado sea el problema (y la búsqueda de paquetes ya está terminada de todos modos). También tenemos algunos archivos relativos con el protocolo path: en nuestro package.json .

Tengo muchos problemas al instalar https://github.com/google/material-design-icons que tiene _ muchos archivos pequeños_ que también parecen ser problemáticos para otras personas (https://github.com/google/ material-design-icons / issues / 518). No sé si mi hardware está roto al manejar muchos archivos pequeños o algo así o si esto está relacionado en absoluto. Nuevamente, mis colegas no tienen tantos problemas para instalar https://github.com/google/material-design-icons como yo.

Actualizar

No estoy seguro ... parece que instalar un paquete con file: pone un módulo en el caché que contiene node_modules/ y otras cosas. Esto es _realmente_ un problema si tiene varios ejemplos, todos con su propio node_modules/ . Parece que .npmignore , etc. se ignoran para las instalaciones de file: . Esto probablemente se reduce a https://github.com/yarnpkg/yarn/issues/2165 , si la solución es _no_ almacenar en caché los archivos resueltos localmente en absoluto. Si abro mi caché ( $ yarn cache dir ) y busco módulos por qué se instalan con file: y contienen un directorio node_modules u otros directorios grandes, puedo acelerar linking phase eliminando estos directorios manualmente. Ahora todo parece instalarse con buena velocidad.

[3/4] Linking dependencies...
Done in 947.71s. 

Tuve que esperar esta cantidad de tiempo para agregar cualquier paquete nuevo con yarn add ...
Win7 / w Yarn v0.21.3
Tengo el paquete material-design-icons en mi aplicación.
Creo que este está relacionado https://github.com/yarnpkg/yarn/issues/990

@kuncevich todo funciona bien por mi parte, durante el tiempo de ejecución de su hilo, agregue el administrador de tareas de inicio ctrl + alt + esc, compruebe qué programa usa la CPU más alta, en mi caso era antivirus, así que tuve que excluir no solo los directorios% appdata% sino también el directorio del proyecto y las cosas volvieron a ser rápidas

@kuncevic , puede que te afecte el error que encontré en Windows: https://github.com/yarnpkg/yarn/pull/2958

Básicamente, el hilo siempre puede copiar todos los archivos en node_modules para cada operación.

@asolopovas en mi caso es node.exe como 10-26 % :

Mi AV no es un problema, incluso si lo apagué por completo, no puedo ver ninguna mejora en la velocidad del hilo.

nodo -v 6.9.2

@kuncevic actualiza tu nodo a 7 y comprueba si eso acelera las cosas, de lo contrario

Básicamente, yarn siempre puede copiar todos los archivos en node_modules para cada operación.

@vbfox, ¿ podría explicar por qué? Estoy mirando la salida detallada de hilo y descubriendo que casi todo el tiempo se dedica a crear directorios y copiar archivos, como parece hacer cada uno individualmente, en lugar de, digamos, crear un directorio para cada _paquete_ y luego copiar el paquete completo, que debería ser un poco más rápido, o incluso simplemente enlazar todos los paquetes que podrían ser más rápidos de nuevo. ¿No es seguro hacerlo?

@danpalmer la fase de vinculación funciona esencialmente en 3 grandes pasos:

1. Encuentre todos los archivos que deben estar en node_modules
2. Verifique esta lista en comparación con lo que ya está allí y encuentre lo que necesita copiarse desde la caché a node_modules
3. Hacer la copia

Debido a un error de libuv / nodejs ( utime es usado por yarn y el error es que establece los milisegundos en cero) los archivos copiados por yarn en una ejecución anterior siempre se encuentran diferentes (la versión en caché tiene un tiempo de modificación normal, pero todos los archivos en node_modules tienen una versión de cero por milisegundos) por lo que la fase 2 siempre informa que todo cambió.

Como el error se corrigió en el nodo 7.1, es bastante fácil de solucionar si no está limitado a LTS (la primera operación de hilo en un repositorio será lenta ya que los archivos se crearon con el error utime pero todo lo siguiente será mucho más rápido). Mi PR esencialmente soluciona esto ignorando la parte de milisegundos de los tiempos de archivo en Windows al compararlos.

Con respecto a copiar el paquete completo, no es una operación que exista en los sistemas de archivos actuales AFAIK, todos funcionan a nivel de archivo.
La mejor ventana que proporciona es una API FileCopy (tengo un PR para usarla en hilo: https://github.com/yarnpkg/yarn/pull/2960) pero es un poco más rápido que usar la API de transmisión nativa de nodejs.

En cuanto al enlace simbólico, no sé por qué no se hace, no tengo el conocimiento suficiente sobre los administradores de paquetes de JavaScript (se realizan algunas modificaciones en los archivos del paquete, como eliminar carpetas de prueba, pero el enlace simbólico de archivos individuales no lo haría diferente) pero como tampoco es el caso en linux / macos (donde es mucho más común que en windows) puede haber una buena razón.

Mi experimento con la actualización a Node 7.8.0 : https://github.com/yarnpkg/yarn/issues/990#issuecomment -290288375

1. Find every file that need to be in node_modules
2. Check this list versus what is already there and find what need to be copied around from cache to node_modules
3. Do the copy

Teniendo en cuenta que la mayoría de las veces las personas vuelven a vincular franjas de bibliotecas cuando cambian de rama, ¿tal vez haya una mejor manera de hacerlo?

¿Podría crear una ID única para cada compilación de node_modules y luego vincular simbólicamente todo el directorio desde una caché? De esta manera, el cambio de las ramas de ida y vuelta es en realidad sólo enlaces simbólicos diferentes node_modules

Por supuesto, estará escribiendo mucho en el disco, ya que ahora está almacenando en caché todas las versiones de node_modules que se encuentre, pero ¿podría haber optimizaciones allí para el enlace simbólico a los directorios de modo que realmente solo esté almacenar un árbol de enlaces simbólicos?

Perdóname por ser ingenuo, no soy el más educado en lo que respecta a los sistemas de archivos de Unix y menos aún de Windows, pero me complacería profundizar en esto, como un ejercicio educativo, y tratar de proporcionar un prueba de concepto de esta idea si no es obviamente defectuoso de ninguna manera.

pnpm e ied emplean algunas de las técnicas que mencionas. Creo que, no del todo seguro, las probé hace algún tiempo, pero causaron problemas en Windows o no fueron tan rápidas como el hilo.

Yo también tuve mucho tiempo para crear-reaccionar-aplicación con hilo
servidor de windows 2012
nodo 7.9.0
hilo 0.22
Hecho en 554.08s.

Pero en otros casos es mucho más rápido si no se incluyen instalaciones de React

No observo mucho tiempo de vinculación recientemente. Corriendo
Hilo - v0.23.2
nodo - 6.10.2 o 7.9.10 (usando nvm para cambiar)

Probé esto en una Mac y Archlinux (Manjaro)

Puedo confirmar que agregar nodo e hilo a las exclusiones de Windows Defender redujo el tiempo de vinculación en alrededor del 60% en mi máquina con Windows.

+1

[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 180.22s.

Cambiar al nodo 7.9.0 no me aceleró. Agregar 'yarn', 'node' y 'npm' a Windows Defender (con y sin extensiones .exe, no estoy seguro de lo que se requiere) lo aceleró 3 veces para mí, pero aún así un 50% más que la instalación de npm.

Además, eliminar toda la protección de cualquier cosa que se ejecute en el nodo o de cualquier paquete que se esté instalando no me parece una buena idea ...

Agregando mi experiencia: agregar node.exe / yarn.exe a la lista de excepciones de Windows Defender redujo nuestro tiempo de instalación de hilo a la mitad (de 60 a 30 segundos).

También veo esto, hace que sea frustrante iterar rápidamente mientras se desarrolla un paquete porque lleva tanto tiempo actualizar un solo paquete.

yarn install v0.24.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 338.20s.

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty

  "dependencies": {
    "autoprefixer": "^6.7.7",
    "axios": "^0.16.1",
    "babel-core": "^6.24.1",
    "babel-loader": "7.x",
    "babel-preset-env": "^1.4.0",
    "coffee-loader": "^0.7.3",
    "coffee-script": "^1.12.5",
    "compression-webpack-plugin": "^0.4.0",
    "css-loader": "^0.28.0",
    "element-ui": "^1.3.3",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.11.1",
    "glob": "^7.1.1",
    "js-yaml": "^3.8.3",
    "node-sass": "^4.5.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^1.3.3",
    "postcss-smart-import": "^0.6.12",
    "precss": "^1.4.0",
    "rails-erb-loader": "^5.0.0",
    "rails-ujs": "^5.1.0",
    "sass-loader": "^6.0.3",
    "style-loader": "^0.16.1",
    "turbolinks": "^5.0.3",
    "vue": "^2.3.0",
    "vue-loader": "^12.0.2",
    "vue-router": "^2.5.3",
    "vue-template-compiler": "^2.3.0",
    "webpack": "^2.4.1",
    "webpack-manifest-plugin": "^1.1.0",
    "webpack-merge": "^4.1.0"
  },
  "devDependencies": {
    "element-theme": "*",
    "element-theme-default": "^1.3.3",
    "eslint": "^3.19.0",
    "eslint-config-airbnb": "^14.1.0",
    "eslint-plugin-import": "^2.2.0",
    "eslint-plugin-jsx-a11y": "^4.0.0",
    "eslint-plugin-react": "^6.9.0",
    "nodemon": "^1.11.0",
    "webpack-dev-server": "^2.4.5"
  }

:(

Agregando mi +1 en MacBook Pro de mediados de verano de 2010 (Sierra 10.12.4) usando yarn 0.24.5, nodo 7.10.0 y npm 4.2.0:

hilo λ añadir bootstrap-sass
hilo añadir v0.24.5
[1/4] 🔍 Resolviendo paquetes ...
[2/4] 🚚 Obteniendo paquetes ...
[3/4] 🔗 Vinculando dependencias ...
[4/4] 📃 Construyendo paquetes nuevos ...
éxito Archivo de bloqueo guardado.
éxito Guardado 1 dependencia nueva.
└─ [email protected]
✨ Hecho en 123.52s.

"dependencies": {
    "@angular/animations": "^4.1.3",
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/material": "^2.0.0-beta.5",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "bootstrap-sass": "^3.3.7",
    "core-js": "^2.4.1",
    "font-awesome": "^4.7.0",
    "material-design-icons": "^3.0.1",
    "materialize-css": "^0.98.2",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
},
"devDependencies": {
    "@angular/cli": "1.0.1",
    "@angular/compiler-cli": "^4.0.0",
    "@types/jasmine": "2.5.38",
    "@types/node": "~6.0.60",
    "codelyzer": "~2.0.0",
    "jasmine-core": "~2.5.2",
    "jasmine-spec-reporter": "~3.2.0",
    "karma": "~1.4.1",
    "karma-chrome-launcher": "~2.0.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.1.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "typescript": "~2.2.0"
}

Volviendo a npm install me lo arregló. Estaba obteniendo - u'stream ': u' [3/4] Vinculando dependencias en yarn y sin error en NPM ..

Quizás algo salió mal con la última versión.

Ejecutando esto a través de Docker.

@iwarner npm 5.0 es una buena opción.

Ejecuto hilo en Vagrant (Ubuntu Xenial) y por Jenkins. Hay dos subproyectos con package.json.
npm -v 3.10.10
nodo -v 6.10.1
instalación de hilo v0.21.3

Pasamos de npm a yarn hace algún tiempo, porque tuvimos un problema de tiempo de espera (4 horas no fue suficiente) para la instalación de npm.

Ahora el hilo funciona aproximadamente el 30% del tiempo, pero el 70% del tiempo tenemos un tiempo de espera de 4 horas en algún momento. Podría ser la primera instalación de hilo, o la segunda, o podríamos agotar el tiempo de espera mientras ejecutamos pruebas unitarias (broma).

Este es un duplicado de https://github.com/yarnpkg/yarn/issues/990 , hay una tabla de comparación y parece que las últimas versiones de Yarn hicieron un buen progreso allí.
Si sigue siendo un problema, presente un nuevo problema con los pasos de reproducción y una comparación con el último npm

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5, 8 GB de RAM

:(

Windows 10 v 1709 + SSD + PowerShell + Nodo 6.12.2:
La instalación de Yarn fue rápida hasta que el último paquete parecía atascarse en un comando de preinstalación.
Seguí las instrucciones aquí para agregar exclusiones para Windows Defender, pero también hice que mi fuente se verificara en la fuente% USERPROFILE%, lo que la ralentizó drásticamente. Comprobado en c: fue mucho más rápido.

¿Alguna solución para la plataforma Ubuntu? Literalmente tengo que pensarlo dos veces antes de agregar un paquete.

Ubuntu es súper rápido para mí, sin lentitud en absoluto.

El viernes 23 de febrero de 2018 a las 11:13, Basant Besra, [email protected] escribió:

¿Alguna solución para la plataforma Ubuntu? Literalmente tengo que pensar dos veces antes
agregando un paquete.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
.

Esto es muy molesto. Literalmente cambié una línea en un módulo, lo republiqué con una nueva versión y yarn add module tomó más de 5 minutos.

Sería más rápido actualizar manualmente mis paquetes usando un editor de texto

También experimento este problema:

success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ @material-ui/[email protected]
info All dependencies
└─ @material-ui/[email protected]
Done in 93.43s.

Mi sistema es Linux manjaro 4.14.31-1-MANJARO #1 SMP PREEMPT Wed Mar 28 21:42:49 UTC 2018 x86_64 GNU/Linux

NodeJS: v9.9.0
Hilado: v1.5.1

También super lento para mí Done in 254.32s.

nodo v8.10.0
npm 5.6.0

OSX 10.11.6 (15G19009)

He vuelto a cambiar a

Estamos usando la función de caché fuera de línea para evitar este problema la mayor parte del tiempo, pero tan pronto como el package.json o yarn-lockfile cambian, volvemos a este problema. La vinculación toma 10 minutos en nuestra máquina Linux. No creo que esto sea específico de Windows.

¡Este definitivamente no es un problema exclusivo de Windows (lo que debería ser evidente en todas las publicaciones de personas en máquinas que no son de Windows)!

Estoy en macOS High Sierra 10.13.4, usando el nodo 10.1.0 (npm 5.6.0) y yarn 1.6.0. Usando hilo, la instalación de una dependencia tomó ~ 40 segundos. Cambié a npm y tardé unos ~ 10 segundos. Me quedaré con npm por el momento.

Lo mismo para nuestra caja centos 7. ¿Alguna actualización sobre esto?
hilo: v1.7.0
npm: v5.7.1

me está sucediendo en 1.9.2 en mac en el nodo 10

Para mí en macOS HighSierra, Avast FileShield estaba causando el problema. Agregué el ejecutable de hilo como ruta excluida, usando which yarn . Parece que está bien ahora, daré una actualización si regresa.

me está sucediendo en 1.9.2 en mac en el nodo 10

Igual que aquí. Yarn 1.9.2, nodo 10.6.0 en High Sierra.

@bestander, esto no es un problema de Windows. Puedo reproducir en mi Mac con Yarn 1.9.4. Este problema debería reabrirse.

@davidgoli , es mejor abrir un nuevo número, este es uno nuevo y debe ser evaluado por separado

Yarn es bastante lento para cualquier entorno en el que lo ejecuté. Debian, Mac, Windows. ¿El nuevo tema estaba abierto? o el RFC que se deshaga de node_modules resolverá esto?

tengo el mismo problema, ya cambié a npm pero todavía tengo un error

También tengo el mismo problema con Yarn. ¿Alguna solución encontrada?

Este es un duplicado del # 990, hay una tabla de comparación y parece que las últimas versiones de Yarn hicieron un buen progreso allí.
Si sigue siendo un problema, presente un nuevo problema con los pasos de reproducción y una comparación con el último npm

Esto no es un duplicado, este problema no se trata solo de Windows. Abrir un nuevo número provocaría una pérdida de contexto.

¡Tengo el mismo problema!

yarn install
yarn install v1.16.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[###############################################---------------------------------------------------------------------------------------------] 22778/67399

Done in 179.59s.

MacOS / Docker

Vagabundo 2.2.4
Invitado: Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
Anfitrión: MacOS 10.14.5 Mojave

hilo 1.16.0
npm 6.9.0

MacBook Pro (Retina, 13 pulgadas, principios de 2015)
Procesador Intel Core i5 de 2,7 GHz
Memoria 16 GB 1867 MHz DDR3

yarn install v1.16.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 1552.45s.

De hecho, no puedo ejecutar yarn install sin perder más de 25 minutos de productividad. Es absurdo. No creo que esto sea un problema de Windows. Me parece muy probable que haya algún problema al ejecutar en un entorno virtualizado. ¿Quizás tenga que ver con carpetas sincronizadas / verificar el estado del archivo en el sistema operativo invitado?

hilo v1.17.3
nodo v10.16.3
npm 6.9.0

Ventanas

Intenté poner la ubicación de la carpeta del proyecto de mi aplicación en la misma sección del disco que yarn cache dir .
directorio de caché de hilo -> C: UsuariosAppDataLocalYarnCachev4

El resultado:
ubicación anterior -> D: myApp Done in 747.17s.
nueva ubicación -> C: myApp Done in 488.97s.

C y D son el mismo disco físico.

Mac

Sin embargo, Mac es más rápido que Windows Done in 121.37s

Creo que el cuello de botella es la velocidad de lectura / escritura del disco.

OS X 10.15
hilo v1.22.4
nodo v12.13.0
npm v6.12.0

Todavía estoy experimentando esto. El proyecto se encuentra en una imagen de disco cifrada montada. La instalación de un solo paquete lleva varios minutos con un package.json relativamente pequeño. No lo he evaluado, pero npm se siente mucho más rápido.

Editar: Resulta que cambiar la carpeta de caché predeterminada de yarn para que esté en el mismo volumen cifrado solucionó esto para mí.

Esto también me golpeó y estoy corriendo:

SO: Ubuntu 18.04.2
Hilado: 1.22.4
Nodo: 14.7.0
NPM: 6.14.7