<p>la instalación de hilo falla con `ENOENT: no existe tal archivo o directorio` ocasionalmente</p>

Interesante, entonces solo falla en Travis, pero ¿funciona cuando se prueba localmente? Eso es muy extraño dado que se supone que Docker asegura que el entorno sea consistente.

@ Daniel15 Lo sé bien ...

He degradado el nodo a la versión 6 y todavía falla en Travis. Agregué la bandera --verbose a yarn install y todo lo que obtuve fue

verbose Performing "GET" request to "https://registry.yarnpkg.com/spawn-wrap/-/spawn-wrap-1.3.4.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs/-/yargs-6.6.0.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-4.2.1.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/fibers/-/fibers-1.0.15.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/selenium-standalone/-/selenium-standalone-5.11.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/tcp-port-used/-/tcp-port-used-0.1.2.tgz".
verbose Performing "GET" request to "https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-5.8.38.tgz".
verbose Error: ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'
    at Error (native)
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol'".

Estoy abierto a ideas sobre cómo depurar esto.

La degradación al hilo 0.18.1 pareció arreglar esto para mí. Parece que 0,19 podría tener una regresión; ver # 1834

También tengo este problema con el hilo 0.23.3, no ocurre cuando se crea una imagen, sino simplemente cuando se ejecuta algún CI.
El error es el siguiente:

$ time yarn --frozen-lockfile
yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/builds/linagora/petals-cockpit/yarncache/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src'".
info If you think this is a bug, please open a bug report with the information provided in "/builds/linagora/petals-cockpit/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

real    0m9.812s
user    0m7.596s
sys 0m0.932s

Creo que puede haber alguna forma extraña de eliminar archivos ...

Punto importante: ¡el caché estaba vacío!

Y en mi máquina, si trato de reproducir, obtengo esto:

yarn install v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: EEXIST: file already exists, mkdir '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/src/metadata'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Y con hilo 0.21.2:

yarn install v0.21.2
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-beta.8.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-beta.8-8d9c8a64e7c26ff7208404e716deea94bb509cd7/bundles/core.umd.js'".
info If you think this is a bug, please open a bug report with the information provided in "/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/frontend/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

¡Eso es terrible!

¡Y estoy de acuerdo con @twooster sobre 0.18.1 funcionando bien!

@ Daniel15 tampoco funciona localmente. En realidad, ¡NUNCA funciona cuando el caché está vacío para mí!

@victornoel, el error reciente podría ser https://github.com/yarnpkg/yarn/issues/2714

@bestander Probé 0.19.1 en ese momento y no funcionó ...

Lo intenté, y ahora el error:

• no aparece con un caché vacío, pero aparece en el siguiente caso (realmente espero que sea reproducible…):
  
  
  
  • rm -rf el caché de hilo
  
  
  • clon https://gitlab.com/linagora/petals-cockpit.git
  
  
  • pago 5f31ccb4b2357201baa50539b30702cffceb6992
  
  
  • ejecutar hilo en el directorio frontend
  
  
  • maestro de caja
  
  
  • ejecutar hilo de nuevo en el directorio frontend
  
  
  • Recibo: error An unexpected error occurred: "http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, utime '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core/testing.js'". (estoy usando mi propio registro, pero lo mismo ocurre sin él)
  
  
• aparece con hilo 0.21.2, 0.19.1 pero no con 0.18.2

Así que no creo que sea lo mismo, esperemos que al menos puedas reproducirlo ...

(en realidad, lo intenté de nuevo y reproduje el error con un caché vacío y un hilo 0.21.2, aunque antes no era el caso, tal vez haya otro archivo en otro lugar que sea la fuente de este problema, y ​​que no esté en el ¿cache?)

@bestander Seguiré probando hilo tan pronto como el # 2744 esté disponible como construcción nocturna :)

Hazme ping si puedo ayudar.
La mejor acción es enviar un PR con una prueba e2e rota (y omitida).

@bestander bueno, no, todavía recibo errores como:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/facade/lang.d.ts'".

o:

➜  frontend git:(master) ✗ yarn
yarn install v0.22.0-20170227.1509
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Veré si puedo hacer una prueba e2e.

@bestander de todos modos, ¿puedo obtener un seguimiento completo del error?

Solo veo esto en el yarn-error.log:

Trace: 
  Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.es5.js'
      at Error (native)

Eso es un poco inútil :)

el error detallado es:

{ Error: http://docker0.gso.lan:8081/repository/npm/@angular/core/-/core-4.0.0-rc.1.tgz: ENOENT: no such file or directory, lstat '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js'
    at Error (native)
  errno: -2,
  code: 'ENOENT',
  syscall: 'lstat',
  path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_type: 'File',
  fstream_path: '/home/vnoel/.cache/yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/@angular/core.js',
  fstream_class: 'FileWriter',
  fstream_stack: 
   [ '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/fstream/lib/writer.js:285:28',
     '/home/vnoel/Linagora/Petals/dev/git/yarn/node_modules/graceful-fs/polyfills.js:284:29',
     'FSReqWrap.oncomplete (fs.js:123:15)' ] }

No estoy seguro exactamente de qué hacer con esto ... está sucediendo en package-fetcher.js , línea 56 exactamente, aunque tengo problemas para encontrar la fuente ...

Parece estúpido, pero siento que falla solo cuando mi espejo npm en red (un nexo de tipo sonat en mi empresa) ha reflejado el artefacto @angular/core . Si no es así, las cosas van bien y luego falla en otro artefacto que ya está reflejado ( typescript en este caso).

Si quito el artefacto del espejo nexus a mano, ¡funciona!

Entonces ... es un poco como si el hilo no pudiera seguir el ritmo si las cosas llegan demasiado rápido ^^ porque cuando uso el registro npm normal sin usar mi espejo, las cosas generalmente van bien (tenemos una conexión a Internet lenta).
Y explicaría por qué a menudo falla en los sistemas CI porque generalmente tienen conexiones a Internet muy rápidas ...

Es un poco exagerado concluir eso, pero podría ayudar a encontrar el origen del problema.
WDYT @bestander?

Para que conste, creo que el error emana del paso tar.Extract en el proceso de búsqueda, pero no estoy totalmente seguro ^^

Gracias por investigar más, @victornoel , es posible que esté en algo aquí.

Puedo reproducir el escenario desde https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896.
Buscando dentro.

yo obtengo

error An unexpected error occurred: "https://registry.yarnpkg.com/typescript/-/typescript-2.2.1.tgz: ENOENT: no such file or directory, lstat '/Users/bestander/Library/Caches/Yarn/npm-typescript-2.2.1-4862b662b988a4c8ff691cc7969622d24db76ae9/lib/typescriptServices.js'".

Sin embargo, si intento yarn install una y otra vez, eventualmente finalizará la instalación.
Parece que la explosión del archivo .tgz termina con un error.

Actualizar:

• el .tgz parece estar bien, puedo descomprimir manualmente el que falla durante la fase de recuperación
• Me pregunto si el paquete tar arroja este error por alguna razón, ¿podría ser concurrencia?

Se agradece algo de ayuda para investigar por qué eliminar esas pocas dependencias (en mi caso, mecanografiado y núcleo angular) provoca errores.
¿Concurrencia? Error en https://github.com/npm/node-tar?

@victornoel , ¿puedes reproducir el error con yarn install --network-concurrency 1 ?

@bestander con --network-concurrency 1 el error no aparece (mientras que sin él, siempre aparece).
Pero, ¿cuál es el valor predeterminado de este parámetro? Cualquiera que sea el valor que elija para él (1, 2, 4, 8), funciona, mientras que si no lo pongo en absoluto, falla ...

El valor predeterminado es 15, puedo reproducir el problema con concurrencia 15 con un pago limpio de https://gitlab.com/linagora/petals-cockpit.git#075bac4c54fee466568c000c7ffe8025f593e212 .

¡Noticias excelentes! Un paso más hacia una solución Y una solución alternativa :)

Algunos resultados.

TL; DR No tengo ideas sobre cómo solucionarlo correctamente para siempre, esto necesita un conocimiento más profundo de Node.js.

1. La red se puede eliminar de posibles problemas.
   He configurado un espejo sin conexión para los archivos .tgz en yarn.lock y puedo reproducir el problema con los paquetes instalados desde el disco.

El problema está en el flujo de descomprimir / descomprimir en el código tarball-fetcher.

1. Probé una biblioteca diferente que extrae tar: https://github.com/mafintosh/tar-fs vs actual https://github.com/npm/node-tar/. Ambos fallan de la misma manera.
   Profundizando un poco más: se producen excepciones en el nodo al realizar varias operaciones mkdirp

Error: ENOENT: no such file or directory, chmod '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts'
  errno: -2,
  code: 'ENOENT',
  syscall: 'chmod',
  path: '/Users/bestander/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.1-7f87b7696b407476e45d6d3c1880a50d5afbb6e3/typings/src/di/injector.d.ts' }

Creo que core-4.0.0 y mecanografiado-2.2.1 fallan porque tienen bastantes archivos y estructuras de carpetas profundas, y no se instalan mientras realizan muchas operaciones simultáneas de mkdir / copy.

Cada vez que falla una llamada al sistema diferente: chmod, rmdir, mkdir, lstat, utime.

Y no es algo obvio en el código de las bibliotecas.

1. Lo mismo falla en los nodos 4, 6 y 7.

2. No pude reproducir el error con la concurrencia establecida en 8, por lo que enviaré un PR para reducir la concurrencia de red predeterminada.

1. Me preguntaba cómo afecta la concurrencia a la velocidad de instalación.

5.1. Usando offline-mirror (sin descarga), en mi MBPro 13 ", limpia la caché y usa node-tar para descomprimir archivos.
Simultaneidad 12 - falla
Simultaneidad 8-18 segundos
Simultaneidad 4 - 18 segundos
Simultaneidad 2 - 21 segundos

5.2. Utilizando offline-mirror (sin descarga), en mi MBPro 13 ", limpia la caché y usa tar-fs para descomprimir archivos.
Simultaneidad 12-15 segundos
Simultaneidad 8-15 segundos
Simultaneidad 4 - 17 segundos
Simultaneidad 2-18 segundos

5.3. Descargando paquetes de Internet, en mi MBPro 13 ", limpie el caché y use tar-fs para descomprimir archivos.
Simultaneidad 12: falló una vez
Simultaneidad 8-21 segundos
Simultaneidad 4 - 23 segundos
Simultaneidad 2 - 34 segundos

Parece que establecer la concurrencia en 8 es lo suficientemente seguro, también tiene sentido cambiar la biblioteca tar.
Seguiré con un PR.

Una forma adecuada de solucionar esto sería bifurcar https://github.com/mafintosh/tar-fs y realizar operaciones de fs más inteligentes, por ejemplo, usando mkdir para cada carpeta solo una vez

El mantenedor de tar-fs parece estar activo, ¿quizás podríamos abrir un problema allí y ver qué saben / proponen sobre esto?

@victornoel , ¿podrías hacer eso por favor?

@bestander hecho! mafintosh / tar-fs # 61 :)

Me encontré con este mensaje de error en un escenario algo similar al probar yarn en los agentes de compilación de mis jenkins.

¿Sabes cuáles son las condiciones necesarias para desencadenar este error? Me gustaría sustituir mi sistema de acumulación npm llamadas con yarn para la velocidad, pero si tengo que desactivar la concurrencia Me preocupa que podría negar cualquier bono allí.

@ProdigySim , como se explica en el # 2829 (que se fusionó en yarn master), la reducción de la concurrencia de la red no tiene un gran efecto en el rendimiento del hilo. Simplemente puede configurarlo en 8 y debería estar bien. De todos modos, incluso al descargar 8 dependencias a la vez, no estoy seguro de que la mayoría de las unidades vayan a seguir en rendimiento, por lo que no perderá mucho con seguridad :)

@victornoel Gracias por la información. No estoy seguro de que solo reducir --network-concurrency sea ​​suficiente en mi caso, ya que también ejecutaríamos varias instancias de hilo en paralelo.

Puedo reproducir este problema incluso con --network-concurrency 1 , pero ¿quizás debería abrir un problema separado para eso?

Usando el mismo repositorio de prueba que dio anteriormente:

#!/bin/bash
set -x # echo commands

# Clear yarn cache
rm -rf $(yarn cache dir)

# Clone the repo into two separate spots
git clone https://gitlab.com/linagora/petals-cockpit.git repo1
git clone https://gitlab.com/linagora/petals-cockpit.git repo2

# Run yarn on both in parallel
cd repo1/frontend && yarn --network-concurrency 1 &
cd repo2/frontend && yarn --network-concurrency 1 &

Esto me da el error cada vez (4 por 4 hasta ahora)

error An unexpected error occurred: "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.2.tgz: 
ENOENT: no such file or directory, lstat '/Users/<snip>/Library/Caches/Yarn/npm-@angular/core-4.0.0-rc.2-59535050e5d0e6141417186eee571296f8e9c3d0/@angular/core.es5.js'".

En hilo 0.21.3, nodo v4.5.0, OSX 10.11.6

Hasta ahora, he podido solucionar este problema al incluir solo hilo en trabajos de compilación que nunca se ejecutarán en paralelo o usar conjuntos de paquetes completamente diferentes, pero incluso entonces no estoy seguro de que sea seguro, por lo que pregunto sobre las condiciones de raíz de este error.

@ProdigySim
Este es un problema separado, pero relacionado, causado por la caché de descarga global de Yarn. Una solución es crear una caché diferente para cada directorio.

Aún puede ejecutar con --network-concurrency 8 . (De hecho, no tengo problemas con la concurrencia de red ilimitada).

Más contexto aquí .

@bestander sorprendentemente, hoy, el problema reapareció (desencadenado por un tar para una nueva versión de angular ^^) incluso con la concurrencia de red en 8, pero solo en mi CI ... Lo moví a 2 y funciona (y no ' Realmente me importa si toma unos segundos más descargar las dependencias, así que está bien por ahora).
No parece que recibamos retroalimentación del proyecto tar-fs… ¿a quién más podemos contactar para que nos ayude en eso?

tener este problema también en mis compilaciones de Travis para OS X. Limpié el caché y configuré la concurrencia de red, pero nada me ayudó.

@kevingelion ¿ a qué valor configuró la concurrencia de red? Sea drástico y establezca algo como 2 para ver si el problema es este :)

@victornoel Lo yarn --mutex network y tampoco dados.

@bestander el siguiente truco corrige (editar: NO) el problema:

diff --git a/src/util/request-manager.js b/src/util/request-manager.js
index e0e134a2..995dac69 100644
--- a/src/util/request-manager.js
+++ b/src/util/request-manager.js
@@ -214,8 +214,7 @@ export default class RequestManager {
     }, params.headers);

     const promise = new Promise((resolve, reject) => {
-      this.queue.push({params, resolve, reject});
-      this.shiftQueue();
+      this.execute({params, resolve, reject});
     });

     // we can't cache a request with a processor

Obviamente, no es una solución, omite completamente el administrador de solicitudes y su sistema de cola, pero muestra que el problema proviene de este subsistema.

¡Gracias Víctor!

El 24 de marzo de 2017 a las 18:07, Victor Noël [email protected] escribió:

@bestander https://github.com/bestander el siguiente truco corrige el
problema:

diff --git a / src / util / request-manager.js b / src / util / request-manager.js
índice e0e134a2..995dac69 100644
--- a / src / util / request-manager.js
+++ b / src / util / request-manager.js
@@ -214,8 +214,7 @@ exportar clase predeterminada RequestManager {
}, params.headers);

 const promise = new Promise((resolve, reject) => {

• this.queue.push ({params, resolver, rechazar});
• this.shiftQueue ();
• this.execute ({params, resolver, rechazar});
  });

 // we can't cache a request with a processor

Obviamente no es una solución, omite completamente el administrador de solicitudes y
su sistema de cola, pero muestra que el problema proviene de este
subsistema.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-289102067 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACBdWF66L-NzAInx7Bhs6V7s7LKahxxUks5rpAZ1gaJpZM4L3JbX
.

lo que no, no lo hace: D pero mejora un poco las cosas

Perdón por el falso positivo, estaba demasiado ansioso por informar mis hallazgos :)

Cambia las cosas porque antes podía ejecutar yarn muchas veces y nunca lograría descargar la dependencia del núcleo angular o el mecanografiado (siempre estos), pero falló la primera vez, y tuvo éxito la segunda vez, y olvidé eliminar el caché entre mis intentos, así que pensé que estaba funcionando.

Bueno, depende, ahora a veces funciona, a veces no (con el truco, por lo que no es una pérdida total o mi conexión a Internet es demasiado lenta en este momento ...)

También me encuentro con esto en nuestras compilaciones de CI. Después de muchas pruebas, finalmente también pude reproducir localmente.

Nuevamente, a veces funciona, pero falla a menudo con cualquiera de los siguientes errores (lo que hace que parezca que hay algún tipo de condición de carrera en alguna parte):

• ENOENT: no such file or directory, lstat 'cache/directory/some-file'
• EEXIST: file already exists, mkdir 'package-name'

Lo aislé en un paquete que instalamos directamente desde un repositorio privado en GitHub. Curiosamente, el paquete al que se hace referencia en el mensaje de error siempre es una dependencia de este paquete (y siempre es otro paquete que instalamos directamente desde GitHub, aunque no un repositorio privado). Entonces, parece que un caso de reproducción es la instalación de paquetes de URL de GitHub privadas que tienen subdependencias que también se instalan desde repositorios de GitHub (no necesariamente privados).

No estoy seguro de si esto ayuda en absoluto ... ¡Estoy feliz de intentar ayudar en todo lo que pueda!

Editar: No estoy seguro de si esto es útil o no, pero el paquete de nivel superior aparece en el formato "git+ssh://[email protected]/org/package.git#v1.0.0" , y en el error, la subdependencia que se está descargando parece que se está descargando sobre https con una URL de "https://codeload.github.com/org/package/tar.gz/ljasdf08i234098aifj" .

Estoy investigando esto un poco más.
Intento construir un script independiente para extractos de tar-fs concurrentes, pero tiendo a pensar que el problema está en la ruptura del archivo tar durante la descarga.

Lo encontré, Doh.

En el ejemplo de https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 Yarn tiene paquetes duplicados que se descargan y extraen en paralelo.
Los duplicados son @angular/core/-/core-4.0.0-rc.1 y typescript/-/typescript-2.2.1.tgz .

Con alta concurrencia, simplemente hacemos una extracción concurrente en la misma carpeta de caché.
Investigaré por qué Yarn no deduplica esos dos paquetes y envía una solución.

No hay magia en el sistema operativo o el nivel de extracción de alquitrán.

jaja, buen trabajo @bestander , ¡me alegro de que finalmente encontramos el problema!

Impresionante trabajo @bestander : tada :! Encontrarnos en https://github.com/yarnpkg/yarn/pull/3090 y https://github.com/yarnpkg/yarn/pull/3106 fue lo que nos impidió usar Yarn.

¡Gracias!

Tuve este problema al instalar el módulo prop-types. Cada vez que intentaba instalarlo ENOENT en un nombre de archivo diferente. Para mí, el problema desapareció después de instalar npm 5.0.2

$ yarn add prop-types
yarn add v0.21.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/prop-types/-/prop-types-15.5.10.tgz: ENOENT: no such file or directory
....

$ npm -g install npm

# whoops, looks like npm installed itself to different location than apt-get did
$ npm -v 
3.5.2

# remove the cached link from shell so the right version can surface
$ hash -d npm
$ npm -v
5.0.2

$ yarn add prop-types
... properly installs prop-types as expected

@skylize Es probable que sea una coincidencia: Yarn no usa el cliente npm en absoluto, por lo que la versión de npm no afecta la ejecución de Yarn en absoluto.

Esto está causando que mis compilaciones de Travis fallen casi todas las veces, con algunos paquetes diferentes. ¿Existe todavía una solución?
error An unexpected error occurred: "https://registry.yarnpkg.com/apollo-client/-/apollo-client-1.8.0.tgz: ENOENT: no such file or directory, utime '/var/lib/jenkins/.cache/yarn/v1/npm-apollo-client-1.8.0-3b5d1976a06a0f82b2fc66fe71754868193dadb9/flow-typed/npm/webpack_vx.x.x.js'".

@Redmega
Lo mismo aquí, pero esto funciona:

yarn install --network-concurrency 1

¿Qué versión está utilizando? Esto está destinado a ser arreglado ya ...

Le 8 août 2017 6:37 PM, "Ben Merckx" [email protected] a écrit:

@Redmega https://github.com/redmega
Lo mismo aquí, pero esto funciona:

instalación de hilo --network-concurrency 1

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-321011749 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAJ0z5qFb7gSW4w14_RbFNjsn4sRYV78ks5sWI7hgaJpZM4L3JbX
.

@victornoel Estoy usando v0.27.5 en la máquina jenkins, al igual que mi local.

Prueba los nightlies: https://yarnpkg.com/en/docs/nightly

La eliminación del archivo yarn.lock y yarn install solucionó el problema.

Esto también hace que mis compilaciones de Jenkins fallen ocasionalmente. Por lo general, funciona después de un segundo intento, pero volverá a fallar más tarde.

@ajcrites @Redmega @headione @benmerckx debería abrir otro problema si está experimentando este tipo de problema. Este problema se ha solucionado con seguridad, por lo que su problema debe ser diferente, incluso si muestra algunos síntomas similares.
Estoy bastante seguro de que hay más posibilidades de que su problema se resuelva si abre otro problema :)

Tenemos el mismo problema, haciendo compilaciones paralelas de paquetes en Jenkins con Node 8.5. Actualmente necesitamos ceñirnos a 0.27.5, hasta que se publique 1.0.2 corrigiendo otro error. Pero gracias por su apoyo y trabajo de todos modos :)

@floric Tengo el mismo problema con el mismo contexto (Jenkins + Parallel) con el nodo 8.9.4, ¿se ha resuelto su problema?

Editar: intentaré usar 8.11.1 para ver si incluye una última versión de hilo sin el error.

@Niceplace puede que quiera probar la opción --mutex : https://yarnpkg.com/en/docs/cli#toc -concurrency-and-mutex

Tenemos planes para agregar un mejor bloqueo por paquete para evitar esto pronto.

Tengo errores intermitentes con ENOENT: no such file or directory, chmod y ENOENT: no such file or directory, lstat tratando de ejecutar yarn --mutex=network en la raíz de un monorepo con el espacio de trabajo Yarn habilitado ...

No parece ser consistente, obtengo uno u otro al azar. (1.6.0 y nodo 8.11.1 y 9.11.1)

Específicamente, los errores son:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/federicozivolo/test/packages/foobar/node_modules/detect-port-alt'".

y

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/Users/federicozivolo/test/packages/foobar/node_modules/jest/node_modules/.bin/jest'".

Estoy ejecutando Yarn 1.7.0 y tengo un error similar. Yarn finalmente logra instalar el paquete después de varias ejecuciones.

An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/nieltg/.cache/yarn/v1/npm-npm-registry-client-8.5.1-8115809c0a4b40938b8a109b8ea74d26c6f5d7f1/lib/dist-tags/fetch.js'".

EDITAR:
He usado yarn --network-concurrency 1 pero el error todavía me ocurre. Aquí hay otra muestra del archivo error y yarn-error.log .

An unexpected error occurred: "ENOENT: no such file or directory, copyfile '/home/nieltg/.cache/yarn/v1/npm-core-js-2.5.7-f972608ff0cead68b841a16a932d0b183791814e/library/fn/date/now.js' -> '/mnt/c/Users/nieltg/Projects/React/React-16-Demo/node_modules/core-js/library/fn/date/now.js'".

Estoy usando Yarn 1.7.0. Y puedo confirmar que me sigue ocurriendo el mismo comportamiento.

Es completamente aleatorio. A veces sucede, a veces no.

Lo último que recibí fue:

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/root/.yarn-cache/v1/npm-@storybook/addon-actions-3.4.5-ba0d0c0c74357c0852e0b890b40

Veo este error con bastante frecuencia con Yarn 1.9.2 en el subsistema de Windows para Linux.

Hoy tenemos problemas similares con paquetes rotos en Jenkins CI donde la canalización ejecuta yarn install en paralelo. Estuvo funcionando bien broma hace unos días.
Se corrigió con yarn install --network-concurrency 1 (como se menciona en un comentario ). El rendimiento no se degradó mucho: ~ 7 segundos -> ~ 8 segundos.

¿Por qué se cerró esto? Todavía sucede:

Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/Users/tommedema/projects/vg/design-to-code/packages/vgcli/node_modules/fs-extra'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/tommedema/projects/vg/design-to-code/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Toms-MacBook-Pro-2:design-to-code tommedema$ yarn install --network-concurrency 1
yarn install v1.9.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 24.85s.

Tenga en cuenta que, en mi caso, desapareció después de hacer yarn remove fs-extra y yarn add fs-extra en dos paquetes, actualizando efectivamente esta dependencia.

Hola, creo que encontré algo.

Estaba incursionando con un fragmento de código que enumera archivos en un directorio específico de forma recursiva usando fs y rxjs y descubrí que es probable que falle si no espero lstat debe finalizar la llamada antes de llamar a otro lstat .

Hice un paquete NPM simple, async-dirtree-test , para probar si su entorno se ve afectado o no por esto. Estoy usando WSL y descubrí que es probable que falle al manejar un directorio que tiene muchos directorios secundarios, como node_modules , incluso con un número bajo de simultaneidad.

Bueno, todavía no sé si este problema es específico de WSL o no. En este momento no puedo probarlo en otro entorno, como Linux, Mac, etc.

@nieltg Quería compartir una observación que podría ayudar a dar forma a algunos de los demás. Estoy usando Docker CE en WSL y Docker para Windows como mi host, así que cuando trabajo con Docker en WSL, se siente nativo, pero en realidad el host opera en el mundo de Windows de forma nativa (por lo que mis Dockerfiles realmente resuelven / c / foobar para c: / foobar en el motor de Docker). Esto es increíblemente relevante cuando uso enlaces (dentro de mi contenedor, estoy montando mis carpetas locales para que / usr / src dentro del contenedor esté finalmente en c: / src / foobar (aunque mi Dockerfile mostraría el enlace como / c / src / foobar: / usr / src (¿ve la traducción automática en la ruta?)

Esta distinción es importante porque si yarn install dentro de una de esas carpetas locales, dentro de mi contenedor, obtengo los mismos errores que hago directamente en WSL (sin Docker involucrado).

Por otro lado ... si solo mkdir /tmp/src && cp ./package.json /tmp/src/ && cd /tmp/src && yarn install , todo funciona perfectamente y puedo solo mv /tmp/src/node_modules /c/src/foobar/ y estoy bien, así que esa es mi solución actual. Tenga en cuenta que /tmp existe como una tienda acoplable (todo el IO se ve como un solo archivo para el sistema operativo porque es efectivamente una partición en un archivo).

Sé que la participación de la ventana acoplable no es ideal aquí, pero parece sugerir que los identificadores rápidos de archivos pueden ser un problema, ya que IO en sí no lo es y podría ayudar a otros a solucionar esto.

... se distrajo y se sometió demasiado pronto. De todos modos, mi cerebro está en otra parte en este momento, pero volveré más tarde y veré si puedo diseñar una prueba usando su enfoque y Docker para sacar más conclusiones.

REABRIR

Recientemente, comenzamos a ver el mismo tipo de error al usar yarn 1.10.1, al ejecutar una compilación de CI en Azure Devops (anteriormente Visual Studio Team Services).

La dependencia real que está fallando parece ser aleatoria lo mejor que puedo decir, pero yarn install se cae intermitentemente con el error ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn........ . Una vez que la compilación funcionará, la siguiente fallará.

La solución alternativa de yarn install --network-concurrency 1 parece funcionar para nosotros.

@ Marclev78 mismo error pero yarn install --network-concurrency 1 no parece funcionar para mí

@ Marclev78 lo mismo aquí, usando yarn 1.10.1 en Azure Devops y obteniendo el error:

Error: https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: ENOENT: no such file or directory, utime 'C:\Users\grpsshagent\AppData\Local\Yarn\Cache\v1\npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636\fn\string\pad-left.js'

A nivel local, todo funciona como se esperaba.

Estoy aquí para decir simplemente que yo también veo este error.

error An unexpected error occurred: "ENOENT: no such file or directory, chmod '/usr/local/opt/asdf/installs/nodejs/8.12.0/.npm/bin/atob'".

Desafortunadamente, creo que tengo que abandonar el hilo para mis binarios de nodos globales y volver a npm hasta que esto se solucione.

Lamentablemente, este problema también comenzó a afectar nuestras compilaciones de CI recientemente; (

La sugerencia de WSL

Creo que las operaciones de escritura y lectura también se comportan de manera diferente. Incluso con mis hacks, con frecuencia veo errores al llamar a fs.writeFile de node (aunque envuelto con bluebird promisify). En cada caso, puedo confirmar que el archivo existe inmediatamente después de recibir el error de escritura.

Estoy enviando una cadena (contenido de archivo XML) a fs.writeFile (), que finalmente llama a lo siguiente, pero no estoy seguro de estar preparado para asumir el desafío que se requiere para configurar una compilación personalizada con depuración adicional salida de este proyecto de C ++, de modo que pueda confirmar exactamente dónde se siente realmente el derecho según el nodo o este módulo de C ++.

La conclusión es que las escrituras no fallan, pero el nodo cree que sí, por lo que el escenario que tiene sentido para mí es que el módulo c + plus está teniendo éxito, pero internamente verifica el archivo y falla, luego los informes no se sienten de espaldas al nodo. y luego se produce la escritura real de modo que cuando voy a buscar el archivo, está allí y el error no tiene sentido.

https://github.com/nodejs/node/blob/master/src/node_file.cc#L1795

@bestander, ¿hay alguna forma de reabrir ese problema? Claramente, esto no está arreglado y afecta a mucha gente.

Confirmar que esto todavía sucede con yarn 1.12 y Azure Pipelines.

Gracias por confirmar a todos.
Parece que hay varias razones para ese error.
Volveré a abrir el problema, aunque se necesita ayuda de la comunidad para depurarlo.

también ocurre con el hilo 1.11, pero no con el 1.10

@bestander - ¿Relacionado? https://github.com/yarnpkg/yarn/issues/6312

Si es así, hay un buen trabajo de reproducción ahí

Este problema también me afecta.

Windows 10 / WSL

"ENOENT: no such file or directory, lstat '/mnt/c/Users/<username>/.cache/yarn/v4/<random_file_in_random_package>"

@limonte WSL tuvo un error por un tiempo que arrojaría aleatoriamente un error similar al ejecutar npm install / yarn install. Ocurría cuando se copiaban muchos archivos a la vez en el disco duro. Asegúrese de tener la última versión de Windows (1809 o superior), ya que puede que no sea causado por el hilo en sí.

También estamos viendo el problema de Extracting tar content of undefined .

error https://registry.yarnpkg.com/eslint/-/eslint-4.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/tmp/yarncache.KTKNZ/v4/npm-eslint-4.19.1-32d1d653e1d90408854bfb296f076ec7e186a300/node_modules/eslint/lib/rules/no-compare-neg-zero.js'"

Hasta ahora, mitigamos esto usando solo una conexión de red concurrente con la opción --network-concurrency 1 . Pero esta es más una solución temporal.

También puedo confirmar el problema en node:11.5.0-alpine .

error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/app/node_modules/<random_pacakge>

Noté que los problemas parecían estar relacionados con la vinculación a la versión del repositorio git de los paquetes.

Reproducir

package.json

{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}

rm -rf node_modules && yarn cache clean && yarn

Solución alterna

Configurar network-concurrency 1 soluciona el problema cada vez.

Ejecutar npm install también funciona.

Notas

La eliminación de cualquier paquete de la lista de dependencias no causa el error, ni tampoco el uso de las versiones npm publicadas de esos paquetes.

Parece arrojar un error diferente cada vez. Parece suceder aleatoriamente a diferentes archivos y con errores ligeramente diferentes.

error https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod  '/home/cameron/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/library/modules/es6.reflect.apply.js'"

Variaciones

• ENOENT: no such file or directory, chmod
• ENOENT: no such file or directory, stat
• ENOENT: no such file or directory, open
• EEXIST: file already exists, mkdir

Otros mensajes

info There appears to be trouble with your network connection. Retrying...

De hecho, acabo de intentar reproducir usando su package.json y apareció un error en el primer intento.

¿Qué capa interactúa el sistema de archivos WSL con el fs NTFS que ya está en su lugar?

¿Están viendo este error en una unidad montada (/ co / mnt / c para ejemplos comunes), o fuera de uno de esos montajes? ¿Hacer una prueba mental alternativa (~ /. Por ejemplo) y reportar alguna diferencia?

Mi intuición me está molestando, pero puedo estar confundiendo los problemas con mis experiencias en la ventana acoplable y necesito verificar esto de forma independiente.

[2/4] Obteniendo paquetes ...
error https://registry.yarnpkg.com/smartwrap/-/smartwrap-1.0.10.tgz : Error al extraer el contenido de alquitrán de indefinido, el archivo parece estar co
rrupt: "ENOENT: no existe tal archivo o directorio, abra 'C: \ Users \ Administrator \ AppData \ Local \ Yarn \ Cache \ v4 \ npm-smartwrap-1.0.10-873ef350d
4ee1262fed4a80a55634d86ae1faf48 \ node_modules \ smartwrap \ ejq '"
info Visite https://yarnpkg.com/en/docs/cli/global para obtener documentación sobre este comando.

¿Están viendo este error en una unidad montada (/ co / mnt / c para ejemplos comunes), o fuera de uno de esos montajes? ¿Hacer una prueba mental alternativa (~ /. Por ejemplo) y reportar alguna diferencia?

¿Existe un caso reproducible de forma coherente en el que esto esté sucediendo? Ha sido bastante aleatorio para mí, pero hago todas mis yarn add -ing en una unidad montada y esto ocurre con frecuencia.

Pude reproducir https://github.com/yarnpkg/yarn/issues/2629#issuecomment -451638917 tanto en una unidad montada como en ~ .

También intenté reproducir https://github.com/yarnpkg/yarn/issues/2629#issuecomment -282745896 pero seguía sin poder obtener el último paquete, que estoy bastante seguro de que no está relacionado.

Tuve el mismo problema en las últimas horas. yarn fallaba aleatoriamente al instalar varios paquetes, mostrando los errores que se mencionaron anteriormente.

Intenté restablecer el caché de hilo y reinstalar y ejecutar con concurrencia de red 1, ninguno de los cuales había funcionado.

Lo que me resolvió el problema fue cambiar a una red diferente (solo usé el AP de mi teléfono en lugar de WiFi) y todo funcionó como por arte de magia.

Tengo el presentimiento de que este problema podría estar relacionado con una recuperación mal manejada por algunos errores de red muy específicos. Lo investigaremos más tarde.

Puedo confirmar el comentario anterior. Establecer network-concurrency no ayuda. Cambiar al punto de acceso telefónico solucionó el problema. Mi entorno: Windows 10 (subsistema Linux - Ubuntu)

Estoy en WSL y había estado viendo este problema con el paquete geo-tz que tiene una estructura de carpetas profundamente anidada (un poco extraña). Probé algunas cosas --network-timeout y --network-concurrency pero no llegué a ninguna parte. Sin embargo, cuando habilité rutas largas en Windows (vea esta publicación de SuperUser ) ahora funciona bien. Quizás esto pueda ayudar a otras personas en WSL. Editar parece que hablé demasiado pronto. Estaba funcionando y la vinculación de dependencias es más rápida, pero ahora veo el mismo error nuevamente.

Aún rompiendo CI ...

Tenemos el mismo problema con Yarn 1.13.0 ejecutándose en una máquina Debian Linux que sirve como nodo esclavo de Jenkins. Tenga en cuenta que tenemos un servidor de repositorio de yarn local, por lo que durante la compilación, no hay (o muy pocas) descargas físicas de los servidores de repositorio de Internet público.

yarn install v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "http://sqrep01.rsint.net:4873/lodash/-/lodash-4.17.10.tgz: ENOENT: no such file or directory, open '/home/jenkins/.cache/yarn/v4/npm-lodash-4.17.10-1b7793cf7259ea38fb3661d4d38b3260af8ae4e7/node_modules/lodash/.yarn-tarball.tgz'".

El archivo real es existente, tanto en nuestro servidor de recompra y en el sistema de archivos.
Si iniciamos la compilación de nuevo, la compilación puede tener éxito o puede fallar con algún otro archivo (aleatorio).
No modificamos la configuración de concurrencia de red predeterminada.

Ditto - Esto sigue siendo un problema, incluso en 1.14

Arguments: 
  /home/jeff/n/bin/node /usr/share/yarn/bin/yarn.js install

PATH: 
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/jkono/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/jkono/AppData/Local/hyper/app-2.1.2/resources/bin:/mnt/c/Users/jkono/AppData/Local/Programs/Microsoft VS Code/bin:/home/jeff/n/bin

Yarn version: 
  1.14.0

Node version: 
  10.15.1

Platform: 
  linux x64

Trace: 
  Error: ENOENT: no such file or directory, scandir '/mnt/c/Users/jkono/dev/PROJECT/node_modules/@storybook/addon-links/src'

También:

➜  yarn cache dir
/mnt/c/Users/jkono/home/.cache/yarn/v4

Esto es bastante molesto, lo vemos a diario en máquinas locales y ci.

Confirmar que esto está sucediendo todo el tiempo en CI también para nosotros

Hola, confirmando que este problema ocurre en nuestro CI.
Esta es la línea del problema.

error https://registry.yarnpkg.com/core-js/-/core-js-1.2.7.tgz : No se pudo extraer el contenido de tar de undefined, el archivo parece estar dañado: "ENOENT: no existe tal archivo o directorio, chmod '/usr/local/share/.cache/yarn/v4/npm-core-js-1.2.7-652294c14651db28fa93bd2d5ff2983a4f08c636/node_modules/core-js/es7/regexp.js' "
info Visite https://yarnpkg.com/en/docs/cli/install para obtener documentación sobre este comando.

El mismo problema comenzó a ocurrir hoy en uno de nuestros proyectos de código abierto.

Puede ver una compilación defectuosa aquí:
https://travis-ci.com/quid/refraction/builds/103692106

Y uno que tiene éxito (con --network-concurrency 1 ) aquí:
https://travis-ci.com/quid/refraction/builds/103693682

¡Espero que pueda ayudar a diagnosticar el problema!

El código fuente del repositorio está en:
https://github.com/quid/refraction

Quizás esto ayude a alguien:
En nuestro CI de Jenkins, el problema era que Jenkins activaba compilaciones paralelas para nuestras aplicaciones, lo que significa que dos (o más) scripts de shell han activado la "instalación de hilo" al mismo tiempo, donde uno de los procesos de compilación ha _eliminado aún más el caché de hilo completamente_ (usando "limpieza de caché de hilo") antes de iniciar la "instalación de hilo". Por supuesto, este fue un problema fatal para los otros procesos de hilo.
Luego eliminamos la limpieza de caché y cambiamos el comando yarn a
yarn install --verbose --prefer-offline --mutex file:/tmp/.yarn-mutex --network-concurrency 1
(_-- verbose_ no es realmente necesario) e insertado
child-concurrency 1
en .yarnrc.
Ahora, cuando se activan las construcciones paralelas, el hilo ha detectado que otro proceso de hilo está activo y ha esperado hasta que finaliza. Esto resolvió los problemas de "no existe tal archivo" en nuestro CI.

Recibo este problema en mi máquina local cada vez que uso una referencia de paquete con este formato:

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git#v3.2.2",

Características notables: paquete privado, URL de github, git + https, referencia de git etiquetada

Pasos que se reproducen para mí:

1. Borrón y cuenta nueva: elimine todas esas referencias y ejecute yarn install . Funciona bien.
2. Agregue todas esas referencias a mi package.json y ejecute yarn install nuevamente, todavía funciona bien en la primera ejecución después de que se agreguen estas referencias.
3. Ejecutar yarn install veces adicionales después de eso funciona siempre que no haya cambios.
4. Sin embargo, modifique cualquier paquete y ejecute yarn install y aparece el error.
5. Si luego elimino todos esos paquetes y ejecuto yarn install , no obtengo el error. Eso nos devuelve al paso 1.

El error se parece a esto:

error An unexpected error occurred: "ENOENT: no such file or directory, open '/Users/jeremy/Library/Caches/Yarn/v4/npm-connect-js-adapter-tls-3.2.2-0c97726d92c21183a7fb7334344eb5047e8bc158/node_modules/connect-js-adapter-tls/.yarn-metadata.json'".

Si elimino todas las referencias de etiquetas git, observo el mismo comportamiento. Así que creo que ese no puede ser el problema.
es decir

"connect-js-adapter-tls": "git+https://github.com/jeremyjs/connect-js-adapter-tls.git",

Ejecutar npm install también da un error:

npm ERR! premature close

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/jeremy/.npm/_logs/2019-03-20T04_38_38_739Z-debug.log

npm-debug.log: https://gist.github.com/jeremyjs/e97381b16f46124ff7a9bd75ad79fd62

Como seguimiento, utilicé una solución alternativa para hacer un script package.json para limpiar esos paquetes de mi caché antes de instalar:

"install-clean": "yarn cache clean connect-js-adapter-tls connect-js-api connect-js-codec connect-js-encode-decode connect-protobuf-messages && yarn install"

¿Hay alguna idea todavía de cuál podría ser este problema?
En nuestro caso, estamos ejecutando yarn install como parte de nuestro CI (contenedor interno de la ventana acoplable) y obtenemos estos mismos errores. Hemos probado yarn cache clean

No estoy seguro de qué más probar en este momento y está deteniendo nuestras compilaciones. 😬

Dan, ¿intentaste ejecutar con --network-concurrency 1? Tengo un similar
escenario y eso resolvió mi problema.
El 2 de abril de 2019 a las 22:17, "Dan Van Brunt" [email protected] escribió:

¿Hay alguna idea todavía de cuál podría ser este problema?
En nuestro caso, estamos ejecutando la instalación de hilo como parte de nuestro CI (dentro de la ventana acoplable
contenedor) y obteniendo estos mismos errores. Hemos intentado limpiar el caché de hilo

No estoy seguro de qué más probar en este momento y está deteniendo nuestras compilaciones. 😬

-
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/2629#issuecomment-479283590 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFU4O1iKA-HBd62Hema1ETmuUlMro_GLks5vdAEOgaJpZM4L3JbX
.

@tevaum que también resolvió el problema de nuestro CI. También ralentizó significativamente nuestras compilaciones. Tan terrible, pero solo una solución.

Si. Es una mala desventaja. Puedes probar con números pequeños como 2 o 4 ...
será un poco más rápido, pero para mí, el único valor que funcionó fue 1: /

Entonces tendremos que esperar a que la solución real sea feliz;)
El 4 de abril de 2019 00:26, "kunokdev" [email protected] escribió:

@tevaum https://github.com/tevaum que también resolvió el problema de nuestro CI.
También ralentizó significativamente nuestras compilaciones. Tan terrible.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/2629#issuecomment-479735791 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFU4O1a9lHn41K0eEQT9zZZzOoATiT61ks5vdXD8gaJpZM4L3JbX
.

¿Se solucionará esto alguna vez? Esto ha inutilizado el hilo en más de uno de mis proyectos.

Utilice la opción mutex, documentada aquí: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

El uso de la memoria caché de Yarn no es seguro de usar de una manera multiproceso y esta es la razón de tales errores.

Alternativamente, puede configurar una carpeta de caché por proceso usando la opción --cache-folder documentada aquí: https://yarnpkg.com/en/docs/cli/cache#change -the-cache-path-for-yarn-

La desventaja de usar la opción mutex es tener solo una instancia de hilo en toda la máquina (otras esperarán hasta que termine el proceso activo) lo que significa que no hay simultaneidad en todos los trabajos de CI.

La desventaja de una carpeta de caché por proceso es un aumento de E / S y algo de potencial perdido debido a una menor reutilización de caché.

La solución ideal sería implementar una implementación de caché segura para el proceso que no es muy fácil debido a la falta de capacidades de bloqueo de archivos en Node (la única opción confiable parece ser la creación de directorios mutex). La segunda mejor opción es utilizar una carpeta de caché por brazo paralelo que permitiría la concurrencia y la reutilización de caché en el mismo brazo.

No creo que sea el tema mutex. Algunos otros y yo ejecutamos un solo hilo a la vez; en mi caso, es solo RUN yarn install en un Dockerfile, durante la fase de construcción de la imagen de la ventana acoplable. Eso hace que sea bastante seguro que ningún otro proceso se esté ejecutando simultáneamente en ese entorno.

Mira este ejemplo de reproducción mínima (al menos para mi OSX):

728 22:49:55 iMac ~/tmp/ynse$ ls
Dockerfile  package.json
729 22:49:58 iMac ~/tmp/ynse$ cat Dockerfile
FROM node
ADD . /app
WORKDIR /app
RUN yarn

730 22:50:00 iMac ~/tmp/ynse$ cat package.json
{
  "dependencies": {
    "react-navigation-core": "https://github.com/react-navigation/react-navigation-core",
    "react-navigation-hooks": "https://github.com/react-navigation/react-navigation-hooks"
  }
}
731 22:50:03 iMac ~/tmp/ynse$ docker build -t yt .
Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> 39337023f8d4
Step 2/4 : ADD . /app
 ---> aa86b2d7f191
Step 3/4 : WORKDIR /app
 ---> Running in 83baa8603935
Removing intermediate container 83baa8603935
 ---> 80741f170292
Step 4/4 : RUN yarn
 ---> Running in 0718118bdcd6
yarn install v1.3.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error An unexpected error occurred: "https://registry.yarnpkg.com/lodash/-/lodash-4.17.11.tgz: EEXIST: file already exists, mkdir '/usr/local/share/.cache/yarn/v1/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d'".
^C
732 22:50:23 iMac ~/tmp/ynse$

@nopik - Yarn 1.3.2 es muy antiguo y hubo numerosas correcciones después de esa versión. ¿Ha intentado utilizar uno de los últimos Docker internos?

De hecho, esa imagen de nodo era bastante antigua. Aquí hay uno nuevo descargado hace unos minutos desde el nodo dockerhub

Sending build context to Docker daemon  15.87kB
Step 1/4 : FROM node
 ---> a9c1445cbd52
Step 2/4 : ADD . /app
 ---> Using cache
 ---> 26ed37136c09
Step 3/4 : WORKDIR /app
 ---> Using cache
 ---> b2339e7d25af
Step 4/4 : RUN yarn
 ---> Running in cdbdfd9c373c
yarn install v1.15.2
warning package.json: No license field
info No lockfile found.
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "ENOTEMPTY: directory not empty, rmdir '/usr/local/share/.cache/yarn/v4/npm-lodash-4.17.11-b39ea6229ef607ecd89e2c8df12536891cac9b8d/node_modules/lodash'".
info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

@BYK ¿Ha intentado construir esta

Lo intentaré en unos días una vez que llegue a mi computadora (ahora en el móvil). Parece muy extraño pero el directorio es consistente. Intentaré ver qué está pasando, gracias por el caso de reproducción.

@nopik : mirando más de cerca el registro, de hecho muestra varias instancias de Yarn ejecutándose en paralelo. Nunca debería ver el mismo mensaje "Resolviendo paquetes" dos veces. No sé por qué está pasando eso, pero estoy 100% seguro de que esa es la razón.

@BYK Ya veo, que uno de esos paquetes tiene "scripts": { "build": "yarn babel --out-dir dist && del-cli 'dist/**/__tests__' && yarn tsc --emitDeclarationOnly", "prepare": "yarn build" } el otro tiene diferentes scripts, pero aún ejecutan yarn en preparación. ¿Son lanzados por yarn durante la instalación?

@Nopik : no crea que esto causaría el problema, ya que simplemente están ejecutando scripts, no otra instalación. Además, esos scripts se ejecutan después de la fase de E / S. Debe haber algo más que active varias instancias yarn install .

Estoy de acuerdo en que probablemente sean varias instancias de hilo ejecutándose al mismo tiempo. El problema es que esto sucede en una sola invocación cli de yarn . Esto no necesita Docker para reproducirse.

Mi teoría, ciertamente mal informada, es que es algo relacionado con el paso de preparación y que yarn podría estar lanzando una instancia adicional para "construir" paquetes git. En particular, apuesto a que son dos dependencias que cada una depende de un paquete común que también necesita ser construido. Yarn intenta ser inteligente y construir cada paquete por separado en paralelo, pero falla cuando intenta construir dos paquetes en la misma ubicación de caché.

En nuestro caso, no tenemos varias instancias de hilo.

Nuestro sistema se ejecuta en su propia imagen de ventana acoplable. Tiene instalación de hilo único _. Comenzó a comportarse mal de repente y ahora no podemos trabajar sin la concurrencia de red establecida en 1.
A menos que el hilo haya cambiado de la noche a la mañana, no veo otro problema que no sea que el hilo esté generando problemas con condiciones específicas.

Si intenta resolver este problema con --mutex file o incluso --mutex network , inevitablemente (probablemente) se encontrará con este error https://github.com/yarnpkg/yarn/issues/6650 (abierto / sin resolver desde hace 6 meses) 😢

Lo que significa que una vez que ejecute yarn install , aunque tendrá éxito, nunca podrá ejecutar otro comando de hilo

Dan, ¿intentaste ejecutar con --network-concurrency 1? Tengo un escenario similar y eso resolvió mi problema.

@tevaum - Ese era exactamente el problema. ¡GRACIAS!
Tenía un script que no pensé que se ejecutaría más de una instancia, pero lo fue. 🤦‍♂️

@tevaum también me resolvió. Gracias.

Si intenta resolver este problema con el archivo --mutex o incluso la red --mutex, inevitablemente (probablemente) se encontrará con este error # 6650 (abierto / sin resolver durante 6 meses)

@sarink - También encontré el error de opción mutex; Gracias a ti por mencionarlo.

yarn dice que todo está bien.

PS C:\Users\chtacklind\Desktop\git\Project> yarn --verbose
yarn install v1.10.1
verbose 0.282 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.284 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.285 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.286 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.288 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.297 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.3 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.301 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.309 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.312 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.318 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.319 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.326 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.327 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.333 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.336 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.346 current time: 2019-05-12T11:56:12.800Z
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.33s.

Sin embargo, ejecutar yarn --check intenta compilar pero siempre falla.

A veces con mensajes de error confusos al final:

PS C:\Users\chtacklind\Desktop\git\Project> yarn --check-files --network-concurrency 1 --mutex file:C:/.yarn-mutex --verbose
yarn install v1.10.1
verbose 0.286 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.288 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.289 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.29 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 0.291 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.292 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.npmrc".
verbose 0.293 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.npmrc".
verbose 0.294 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.npmrc".
verbose 0.295 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 0.296 Checking for configuration file "C:\\Users\\.npmrc".
verbose 0.302 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.304 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.305 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.306 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.307 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 0.308 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.311 Found configuration file "C:\\Users\\chtacklind\\Desktop\\git\\Project\\.yarnrc".
verbose 0.313 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\git\\.yarnrc".
verbose 0.314 Checking for configuration file "C:\\Users\\chtacklind\\Desktop\\.yarnrc".
verbose 0.315 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.316 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 0.317 Checking for configuration file "C:\\Users\\.yarnrc".
verbose 0.32 current time: 2019-05-12T11:56:20.033Z
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.344 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.345 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 2.345 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 2.346 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 2.347 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\.npmrc".
verbose 2.348 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.349 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.35 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.351 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 2.352 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\ef8122f161347726dd1763e1dca6eeef.d34344cbdf2ff518a03c08fc5f46827c9d66e543.prepare\\.yarnrc".
verbose 2.353 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 2.358 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 2.359 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 2.36 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 2.361 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 2.362 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 2.363 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.364 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 2.366 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 2.541 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.263 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.264 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.265 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.266 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.268 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.27 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.271 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.273 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.278 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.279 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.28 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.281 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.283 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.285 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 5.007 Error: https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"nd\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)pData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
    at Extract.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:56849:14)a\\Local\\Yarn\\Cache\\v2\\.yarnrc".
    at Extract.emit (events.js:194:15)on file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
    at Extract.module.exports.Extract.destroy (C:\Program Files (x86)\Yarn\lib\cli.js:131115:17)nrc".
    at onunlock (C:\Program Files (x86)\Yarn\lib\cli.js:130992:26)nd\\AppData\\Local\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43373:25rs\\chtacklind\\AppData\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:43339:23rs\\chtacklind\\.yarnrc".
    at C:\Program Files (x86)\Yarn\lib\cli.js:56799:13acklind\\.yarnrc".
    at FSReqWrap.oncomplete (fs.js:153:21)ile "C:\\Users\\.yarnrc".
error https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\lib\\tsserver.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

A veces con diferentes errores:

...
[2/4] Fetching packages...
verbose 2.635 Performing "GET" request to "https://registry.yarnpkg.com/typescript/-/typescript-3.3.3333.tgz".
verbose 3.465 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.466 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.467 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\npmrc".
verbose 3.468 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.npmrc".
verbose 3.469 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.npmrc".
verbose 3.47 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.npmrc".
verbose 3.471 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.npmrc".
verbose 3.473 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.npmrc".
verbose 3.474 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.npmrc".
verbose 3.48 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.npmrc".
verbose 3.481 Checking for configuration file "C:\\Users\\chtacklind\\.npmrc".
verbose 3.482 Checking for configuration file "C:\\Users\\.npmrc".
verbose 3.483 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.485 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.486 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.49 Checking for configuration file "C:\\Program Files\\nodejs\\etc\\yarnrc".
verbose 3.492 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\6621674c4e43b664dde14df71eaf0cc8.09d44d8abc94f728f1c5ea93c22fe9b4f87d9076.prepare\\.yarnrc".
verbose 3.493 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.tmp\\.yarnrc".
verbose 3.494 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\.yarnrc".
verbose 3.495 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\.yarnrc".
verbose 3.496 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\.yarnrc".
verbose 3.497 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\Local\\.yarnrc".
verbose 3.501 Checking for configuration file "C:\\Users\\chtacklind\\AppData\\.yarnrc".
verbose 3.503 Checking for configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.504 Found configuration file "C:\\Users\\chtacklind\\.yarnrc".
verbose 3.505 Checking for configuration file "C:\\Users\\.yarnrc".
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 4.608 Error: EPERM: operation not permitted, unlink 'C:\Users\chtacklind\AppData\Local\Yarn\Cache\v2\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\.yarn-tarball.tgz'
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\Users\\chtacklind\\AppData\\Local\\Yarn\\Cache\\v2\\npm-typescript-3.3.3333-171b2c5af66c59e9431199117a3bcadc66fdcfd6\\.yarn-tarball.tgz'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\chtacklind\\Desktop\\git\\Project\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS C:\Users\chtacklind\Desktop\git\Project>

Observe que se están ejecutando dos procesos de hilo a pesar de que tengo --mutex especificado.

Es de destacar que este paquete tiene una dependencia de git que tiene un paso tsc prepare que debe realizarse. Ese paquete también tiene una dependencia de git que requiere el mismo proceso. Está claro que el hilo está tratando de desempacar el mismo paquete en el mismo lugar y estamos obteniendo una condición de carrera.

¿Por qué Yarn ejecuta varias instancias incluso cuando se le dice que no lo haga?

Como actualización, el uso de yarn install --network-concurrency 1 --mutex network parece funcionar cada vez que el uso de una u otra opción tiende a tener éxito solo una parte del tiempo.

Entonces, ¿cuál es la solución para este problema?
Yo uso yarn 1.16 en Ubuntu Linux 18.04
Y sigo recibiendo este mensaje de error:

error Se produjo un error inesperado: "ENOENT: no existe ese archivo o directorio, lstat '/ home / user / workspace / project / packages / components / node_modules / source-map-support'".

Mi comando es:

yarn install --check-files --frozen-lockfile --network-concurrency 1

Y recibo este error una de cada dos veces: ((
PD: trabajo en monorepo, así que he habilitado los espacios de trabajo de hilo
PPS:
Yo comprobé dos veces
Agregar un archivo --mutex o una red --mutex no ayuda.

La única solución que puedo confirmar que funciona es poner un script

until
    yarn install --check-files --frozen-lockfile;
do
    echo "Surprise, surprise. Let's try again..."
done

:(

Fwiw, pude cambiar a npm sin hacer nada más que buscar / reemplazar yarn con npm , usando synp para convertir yarn.lock en package-lock.json y ejecutando npm install . Pensé que este sería un proceso doloroso, pero npm ha avanzado mucho y solo me tomó unos 30 minutos y ahora simplemente funciona en todas partes.

Parece que el problema aquí es que no hay un ejemplo realmente simple de lo que está fallando. Publiqué un package.json trivial que reproduce de manera confiable el problema para mí, pero los paquetes incluidos son algo complicados.

Sospecho que el problema es cuando tienes un árbol de dependencia con "hojas" / consejos compartidos que toman tiempo para compilar / instalar (preparar) y el hilo intenta hacer esto prepararse dos veces, al mismo tiempo. Cada instancia está "preparada" en una ubicación predecible compartida y ambos no pueden "escribir" en la misma ubicación al mismo tiempo (uno elimina un archivo mientras que el otro espera que todavía esté allí).

He querido crear algunos paquetes simples de prueba de concepto con pasos de "preparación" inflados para probar esta teoría, pero no he tenido tiempo. ¿Quizás alguien más pueda probar esta teoría antes de que yo llegue a ella?

Esto sucede cuando tiene varias instancias de hilo ejecutándose al mismo tiempo. Puede usar la opción --mutex documentada aquí: https://yarnpkg.com/en/docs/cli/#toc -concurrency-and-mutex

@BYK Parece que hay muchos casos en los que este no es el problema. Otros incluso han indicado que esta opción les causa otros problemas.

@cinderblock # 6650 parece un caso límite y no debería afectar realmente la resolución de este problema. El otro ejemplo que menciona es que aún se activa hilo en modo de instalación durante otra instalación, lo que probablemente sea un paquete problemático ya que no debería activar otra instalación durante la instalación de su paquete. Esto también se puede evitar con --ignore-scripts que también se recomienda.

Si tiene otros clientes potenciales, compártalos para que, con suerte, alguien pueda dedicar más tiempo a depurarlo.

@BYK No he visto a nadie usar intencionalmente yarn install dentro de un script install . ¿Viste este package.json trivial que produce este problema? Por supuesto, es algo en los paquetes dependientes lo que provoca este error, y tal vez tengan un install enterrado al que te refieres. Sin embargo, ese package.json funciona bien con npm ...

Relacionado, ¿cómo / dónde se recomienda --ignore-scripts ? Muchos paquetes dependen de scripts posteriores a la instalación para funcionar.

Relacionado, ¿cómo / dónde se recomienda --ignore-scripts? Muchos paquetes dependen de scripts posteriores a la instalación para funcionar.

Oh, solo lo recomendé aquí y creo que muchos miembros de Yarn expresaron su opinión sobre esto. 😀 La mayoría de los paquetes están bien, pero de hecho hay algunos paquetes que dependen de scrpits posteriores a la instalación, sí.

¿Viste este paquete trivial.json?

Sí, pero incluso un archivo package.json "trivial" puede ceder a un árbol de dependencias muy grande, por lo que decir que es trivial, no cambia mucho, excepto que tiendo a interpretarlo de una de las siguientes maneras:

• el hilo es demasiado malo, por lo que ni siquiera puede lidiar con este archivo _trivial_ package.json
• este problema se puede reproducir con un archivo _trivial_ package.json, pero aún no puede / no puede solucionarlo

donde ninguno de ellos es útil, por lo que tiendo a ignorar ese comentario tuyo.

Para el problema real, para que el hilo se ejecute con el mutex, todas las instancias de hilo deben llamarse con la bandera --mutex , por lo que la mejor manera de ver si esto soluciona el problema es agregar --install.mutex network a .yarnrc archivo (consulte https://yarnpkg.com/en/docs/yarnrc#toc-cli-arguments). Dicho esto, esto puede dar lugar a un punto muerto si la instalación inicial activa otra instalación, donde la segunda instalación esperará a que finalice la principal y la principal se bloqueará en este hilo invocado por script para finalizar, por lo tanto, realmente no Sepa cómo solucionar este problema además de implementar un sistema de caché seguro para subprocesos / procesos, que es casi imposible con las primitivas de bloqueo que proporciona node . Lo más parecido parece este paquete de bloqueo adecuado, pero ninguno de nosotros tuvo tiempo de probarlo. Puedo ayudarlo si está interesado en intentar implementar esto en el código de escritura / lectura de la caché.

@BYK Oh, mis disculpas si salí así. No había visto una forma de reproducir el error de manera confiable antes de eso, incluso si todavía no está lo suficientemente destilado para solucionar el problema. Ese fue todo mi ímpetu para ese comentario.

Perdone mi persistencia, pero todavía no veo cómo la opción mutex es una solución. Intenté ejecutar con mutex y todavía corría hilo al mismo tiempo. ¿Quizás cometí un error en mis pruebas ? Esperaba que la ejecución de yarn --mutex ... pasara esa opción a las instancias secundarias (como lo hace make , por ejemplo). También he probado su sugerencia de agregar --install.mutex network a mi archivo .yarnrc sin éxito (los mismos errores). --verbose confirma que se están cargando las opciones.

¿Quizás podríamos llegar a esto desde una dirección diferente? ¿Qué hace el hilo que npm no? ¿Por qué npm no tiene este mismo problema?

@BYK , usar la bandera mutex es completamente inaceptable, porque hay un error de hilo adicional que evitará que _ nunca ejecutes otro comando de hilo _ ... Esto es como si tu solución a "Bloqueé mis llaves en mi auto "era," no te preocupes, ¡pensé en eso! Solo usa esta práctica herramienta para golpear todas tus ventanas y cerraduras de puertas, ¡ahora nunca podrás volver a cerrar tu auto! 🙄

Trivial package.json o no, este es un gran problema sin solución o solución que hace que el hilo sea completamente inutilizable para muchas personas. Debería recibir más atención. Especialmente considerando que ha estado abierto durante _ dos años_.

@sarink

@BYK , usar la bandera mutex es completamente inaceptable, porque hay un error de hilo adicional que le impedirá ejecutar otro comando de hilo ...

No tengo conocimiento de un error de este tipo, ¿puede indicarme si ya se informó? La forma en que funciona --mutex es para evitar que se ejecute cualquier otra instancia yarn utilice el mismo mutex, hasta que finalice la inicial. Entonces, lo que dices (no tu descripción) me suena a "funciona como se esperaba".

Trivial package.json o no, este es un gran problema sin solución o solución que hace que el hilo sea completamente inutilizable para muchas personas. Debería recibir más atención. Especialmente teniendo en cuenta que ha estado abierto durante dos años.

Tal vez debería tomarse un minuto para reflexionar sobre la contradicción interna de su propia frase: "deja el hilo completamente inutilizable para mucha gente" y "ha estado abierto durante dos años". Solo hay 56 participantes en este número, que incluye ~ 5 mantenedores de Yarn y un total de 138 comentarios, la mayoría de ellos girando alrededor de las mismas cosas. Esto no es "mucha gente", son _algunas_ personas y seguro que es importante para ellos, pero veo que ninguno de ellos toma esto como importante para enviar una sola línea de corrección de código y simplemente exigir correcciones para un software que se proporciona por completo. gratis para ellos.

@cinderblock

Perdone mi persistencia, pero todavía no veo cómo la opción mutex es una solución.

Nada que perdonar con respecto a la persistencia, en realidad es para celebrarlo mientras intentas resolver el problema :)

Esperaba que la ejecución de yarn --mutex ... pasara esa opción a las instancias secundarias (como make, por ejemplo).

Estoy bastante seguro de que no se transmite.

También probé su sugerencia de agregar la red --install.mutex a mi archivo .yarnrc en vano (los mismos errores). --verbose confirma que se están cargando las opciones.

Eso es muy interesante. Quizás se deba a que la nueva instancia de hilo se activa desde otro directorio, ignorando su archivo .yarnrc . Puedo sugerir el uso de un archivo .yarnrc global con esa opción, que dice que no creo que sea una solución adecuada. Solo deberíamos probar esto para ver si realmente bloquea la instalación como esperábamos anteriormente.

¿Quizás podríamos llegar a esto desde una dirección diferente? ¿Qué hace el hilo que npm no? ¿Por qué npm no tiene este mismo problema?

Aprecio el pensamiento diverso, que dijo que Yarn y npm son tan diferentes en cómo funcionan, no creo que esto realmente se aplique aquí. Si podemos identificar qué paquete desencadena una instalación de hilo como parte de su propia instalación, podemos encontrar una solución. ¿Quizás pueda reemplazar el ejecutable yarn con algún script bash que registre la fuente de invocación, cwd y todos los argumentos pasados ​​y luego ejecute yarn como de costumbre para obtener información útil de depuración y continuar desde allí?

La solución definitiva sería una implementación de caché compatible con la concurrencia como mencioné anteriormente, pero con más información de depuración, es posible que podamos encontrar una solución alternativa más económica.

Muchas gracias por su cooperación con este @cinderblock , muy apreciado.

La solución definitiva sería una implementación de caché compatible con la concurrencia como mencioné anteriormente, pero con más información de depuración, es posible que podamos encontrar una solución alternativa más económica.

Supongo que debería ser posible proporcionar un manejo de concurrencia simplificado, por ejemplo, si se invocan otras instancias de hilo durante el paso de construcción, debería haber muy pocas operaciones de caché por el proceso de hilo superior. Al menos, eso es lo que esperaría. Asegurarse de que la caché se vacíe en el disco antes de invocar cualquier posible script podría ser suficiente. Sin embargo, no estoy seguro de qué tan complejo es implementarlo.

@BYK ¡Oh! No había considerado la posibilidad de que un subpaquete llamara yarn ... en un script. ¿Estás pensando que la razón por la que npm install no falla es porque cuando sus dependencias se ejecutan yarn ... solo hay una instancia en ejecución?

me las arreglé para resolver el problema con la ejecución

yarn cache clean
rm ./yarn.lock
yarn install

Este proceso, sin embargo, lleva años, porque descarga todos los paquetes nuevamente porque a) ya no tienes caché y tu archivo de bloqueo ha sido eliminado.

Esto podría resolverse en su máquina local, pero el problema con el hilo persiste en caso de que se use en bitrise. Es una imagen limpia, desde cero. En cualquier caso, se requiere la concurrencia de la red, incluso cuando se está ejecutando un proceso de hilo único.

@BYK

Solo hay 56 participantes en este número, que incluye ~ 5 mantenedores de Yarn y un total de 138 comentarios, la mayoría de ellos en torno a las mismas cosas.

Parece un número bastante alto para este repositorio. Es el total de comentarios más alto entre todos los temas abiertos y cerrados, y se encuentra entre los conteos más altos de participantes.

Es más, mientras investigaba un problema (probablemente) relacionado, vi a bastantes personas con problemas que probablemente estaban relacionados. Lo desafortunado es que muchas de estas personas abandonaron el hilo en su totalidad o se tragaron el costo de hacer --network-cocurrency 1 cada vez que cambiaba el archivo de bloqueo del hilo. Eso es exactamente lo que estaba haciendo para uno de mis proyectos hasta que finalmente descubrí que era un subguión.

Esto no es "mucha gente", son algunas personas y seguro que es importante para ellos, pero veo que ninguno de ellos toma esto como importante para enviar una sola línea de corrección de código y simplemente exige correcciones para un software que se proporciona por completo. gratis para ellos.

Yarn no es el tipo de proyecto en el que la gente puede lanzarse fácilmente. Es un sistema complejo que hace muchas cosas de manera asíncrona, lo que significa que no puede simplemente colocar un depurador y subir la pila para ver qué está sucediendo. Como tal, de ninguna manera es fácil de entender esta base de código, y es aún más difícil de modificar. Demonios, en este punto ya he pasado unos días de tiempo acumulado leyendo el código y todavía no me siento lo suficientemente seguro como para enviar ni siquiera un simple parche con pruebas relevantes. Dado que tengo más de dos décadas de experiencia y que la lectura de código es una de mis especialidades, no le daría a un desarrollador promedio las mayores oportunidades.

En otras palabras, lo que puede ser una solución rápida y simple de una sola línea para usted puede ser un gran proyecto de varios días para alguien que no esté familiarizado con el funcionamiento interno del proyecto. Esto es antes de mencionar las políticas implícitas que existen en varias comunidades. Me han negado al menos algunas relaciones públicas en varios proyectos de código abierto porque no seguí algún protocolo, ni escribí la prueba correcta, no obedecí la especificación correcta, o incluso por tener una solución que no cumplía con algunos estándares de codificación indocumentados. Puede ser un desafío contribuir de manera significativa a grandes proyectos como forastero.

Si esto realmente es una solución de una sola línea para usted, ¿no sería más rápido simplemente escribir esa solución en lugar de escribir una publicación larga criticando a otros por no hacerlo?

Si podemos identificar qué paquete desencadena una instalación de hilo como parte de su propia instalación, podemos encontrar una solución.

Tengo un ejemplo de un paquete que muestra este tipo de comportamiento aquí , aunque no veo un yarn install allí (a menos que el bob build haga, aunque también mostró este problema cuando el comando fue "prepare": "node ./scripts/generate-mappings", ).

La solución definitiva sería una implementación de caché compatible con la concurrencia como mencioné anteriormente, pero con más información de depuración, es posible que podamos encontrar una solución alternativa más económica.

Un buen punto de partida sería una advertencia si se detecta una situación de este tipo (suponiendo que sea detectable). Un caché compatible con la concurrencia parece que tendría que ser un esfuerzo concentrado de al menos un miembro de la comunidad de hilos.

La actualización encontró una solución que funciona ... un submódulo de git y luego hacer que la ubicación del paquete sea la carpeta local. No es ideal, pero funciona.

También estamos teniendo este problema en CircleCI y es un gran problema. El problema parece estar relacionado con el uso de un paquete alojado en github.com y quizás Linux (funciona en OSX). mutex opciones network-concurrency no hacen nada.

"my-js-lib": " ssh: //[email protected] : dgobaud / my-js-ib # 1.0.0"

si elimino que funciona en CircleCI. Localmente funciona con él en OSX con hilo 1.17.0.

Pero no funcionará en CircleCI con el nodo 12.8.1 y el hilo 1.17.3 (imagen del círculo circleci / nodo: último)

O con el nodo 8.15.0 y el hilo 1.12.3 (imagen del círculo circleci / nodo: 8.15.0)

#!/bin/bash -eo pipefail
yarn install --mutex network --network-concurrency 1
yarn install v1.12.3
[1/4] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^0.4.3"
[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...
$ cd functions && yarn install
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Resolution field "[email protected]" is incompatible with requested version "mixin-deep@^1.2.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.0"
warning Resolution field "[email protected]" is incompatible with requested version "set-value@^2.0.1"
[3/5] Fetching packages...
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/lodash/-/lodash-4.17.15.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/home/circleci/.cache/yarn/v4/npm-lodash-4.17.15-b447f6670a0455bbfeedd11392eff330ea097548/node_modules/lodash/_arrayReduceRight.js'"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
info There appears to be trouble with your network connection. Retrying...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code 1

--network-concurrency 1 tiene éxito, --network-concurrency 8 falla, en circleCI / node: 10

¿Puede alguien ayudarme a entender por qué Yarn necesita fallar en EEXIST y EOENT?

En el caso de EEXIST, esperaría que Yarn lo advirtiera y luego anulara el archivo.
En el caso de EOENT, esperaría que Yarn cree la carpeta que falta (que suele ser la causa del problema).

Entiendo que puede tener efectos secundarios, por lo que tal vez este comportamiento podría hacerse más estricto con una bandera (o viceversa).

Pero, ¿cuál es el punto de mantener estos errores? No son útiles para nadie.

@BYK Lo siento, acabo de ver tu comentario

No tengo conocimiento de un error de este tipo, ¿puede indicarme si ya se informó? La forma en que funciona --mutex es para evitar que se ejecute cualquier otra instancia yarn utilice el mismo mutex, hasta que finalice la inicial. Entonces, lo que dices (no tu descripción) me suena a "funciona como se esperaba".

Este es el error: https://github.com/yarnpkg/yarn/issues/6650 como se menciona en https://github.com/yarnpkg/yarn/issues/2629#issuecomment -481297806 (que creo que ahora está enterrado bajo el "mostrar más historial" en este hilo)

Solo hay 56 participantes en este número

Bueno, supongo que es un buen punto

Este error todavía está en yarn v1.19.1. No entiendo por qué Yarn Team no repara este molesto error.
aquí está mi .yarnrc y no ayuda:

save-prefix ""
--install.check-files true
--add.check-files true
--remove.check-files true
--install.frozen-lockfile true
--add.frozen-lockfile true
--remove.frozen-lockfile true
--install.mutex network
--install.mutex file

Lo que acabo de descubrir es que ejecutar npx lerna clean && ./yarn-install-in-loop.sh ayuda.
Limpiar (eliminar) todos los directorios node_modules en mi monorepo ayuda.

@gitowiec puede confirmar. Mis invocaciones yarn install contenedor son datos que compiten con algo en el sistema de archivos, y cada intento de limitar yarn a un solo archivo .yarnrc falla. Me rindo y vuelvo a npm .

Descubrí que mi problema era tener dependencias de paquetes de repositorios git a través de múltiples niveles (es decir, mi paquete -> paquete git -> paquete git -> paquete git). Además, la caché durante la instalación no funcionó bien en comparación con npm (npm solo realiza el pago una vez, pero el procesamiento de hilo varias veces el mismo paquete durante la misma instalación).
Me estoy moviendo de nuevo a npm. Funciona bien desde v6.

A mencionado anteriormente, este problema aún existe. Esto es lo que hemos agregado a nuestro config.yml para que circleci haga que nuestras pruebas pasen:
- run: name: Yarn Install source ~/setyarnpath.sh i=5; until yarn; do echo "Yarn failed. Retrying..."; ((i--)); if [[ "$i" == '0' ]]; then break; fi; done

Estaba teniendo el mismo problema. Usando macOS, y docker-compose, con un volumen de host [1] que tenía mi código Y node_modules dentro.

Se modificó node_modules para que esté dentro de un volumen anónimo , pero supongo que un volumen con nombre también funcionaría. Y parece estar funcionando bien ahora, y también instalando las dependencias MUCHO más rápido.

Mi archivo docker-compose cambió de:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
    ports:
      - "3000:3000"
    ...

A:

services:
  ...
  web:
    build: .
    volumes:
      - .:/home/example
      - /home/example/node_modules
    ports:
      - "3000:3000"
    ...

[1] https://success.docker.com/article/different-types-of-volumes

Veo un nuevo error con yarn reciente que creo que es un nuevo síntoma de este problema.

yarn stdout [1/4] Resolving packages...
yarn stdout [2/4] Fetching packages...
yarn stderr error https://registry.yarnpkg.com/prettier/-/prettier-1.19.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "EEXIST: file already exists, mkdir '/home/pi/.cache/yarn/v6/npm-prettier-1.19.1-f7d7f5ff8a9cd872a7be4ca142095956a60797cb-integrity/node_modules/prettier'"
yarn stdout info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn stderr Process stalled
yarn stderr Active handles:
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - Socket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket
yarn stderr   - TLSSocket

Nota: yarn stderr/out son el prefijo que mi programa le da a la salida del hilo en mi env

Creo que este es el mismo problema porque mi proyecto podría crear de manera bastante consistente los viejos síntomas de la misma manera que estos nuevos síntomas están sucediendo (y los viejos síntomas se han detenido).

Como referencia, esto sucede en la instalación después de que borro el caché de hilo y node_modules o actualizo una dependencia de paquete git en particular.

La dependencia del paquete en particular es una dependencia de otro paquete git del que realmente dependo (ambos tienen pasos prepare similares que dependen de TypeScript). Si realizo cambios en estas dependencias en #master y hago un yarn upgrade --latest , se produce el problema (y en las siguientes yarn install .

Cuando actualizo ese subpaquete manualmente (¡en una carpeta node_modules completamente separada!), yarn install vuelve a funcionar. Esto me hace pensar que el hilo está usando accidentalmente la caché por dos procesos al mismo tiempo y esto está causando los problemas que estamos viendo en este problema.

Esto me sucede cuando uso 2 o más paquetes instalados por dependencia de git. De alguna manera, hay varios procesos en el mismo paquete que ejecuta el script prepare . Además, comienza a fallar con npm también en las últimas versiones.

Dependencies:
A -> B & C (both by git, with prepare script)
B -> C (by git, with prepare script)

Esto se ha abierto durante años y todavía sucede con el hilo 1.22.0.
Solo he pasado horas tratando de depurar lo que estaba pasando sin suerte, y parece que no he sido el único.

La única solución que veo ahora es cambiar a npm.

@gregory En mi caso, recuerdo que en junio de 2019, el hilo siempre terminaba instalando los paquetes necesarios, incluso si tomaba de 2 a 4 repeticiones para llegar allí. Además, incluso con estas repeticiones, el hilo seguía siendo más rápido que las npm.

Volvería a ejecutar hasta que el hilo termine de usar comandos como este:

while ! yarn install; do echo --- ; done

La solución fácil para nosotros fue publicar un paquete privado y usarlo en lugar de un enlace de git. Aunque sigue siendo molesto

while ! yarn install; do echo --- ; done

Realmente triste que la única solución sea la fuerza bruta ... increíble que nadie haya solucionado esto todavía.

cc @arcanis

Probar dos instalaciones de hilo posteriores, funciona la primera vez y luego falla.

Gestión de dependencias rápida, fiable y segura.

Eso es poco confiable.
`` [3/5] Recuperando paquetes ...
error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: No se pudo extraer el contenido de tar de indefinido, el archivo parece estar dañado: "ENOENT: no existe tal archivo o directorio, enlace '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node '->' /apparn /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-integration / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Visite https://yarnpkg.com/en/docs/cli/install para obtener documentación sobre este comando.
[1/5] Validando package.json ...
[2/5] Resolviendo paquetes ...
[3/5] Recuperando paquetes ...
info Parece haber problemas con la conexión de red. Reintentando ...
info [email protected] : La plataforma "linux" es incompatible con este módulo.
info " [email protected] " es una dependencia opcional y una verificación de compatibilidad fallida. Excluyéndolo de la instalación.
info [email protected] : La plataforma "linux" es incompatible con este módulo.
info " [email protected] " es una dependencia opcional y una verificación de compatibilidad fallida. Excluyéndolo de la instalación.
[4/5] Vinculando dependencias ...
[5/5] Construyendo paquetes nuevos ...
$ npm ejecutar preparar: mjs && npm ejecutar preparar: js

[email protected] prepare: mjs /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
BABEL_ESM = 1 babel src -d. --keep-file-extension

Compilado con éxito 39 archivos con Babel.

[email protected] prepare: js /app/.cache/yarn/v6/.tmp/43563e016bb56318ebd76037a0f6ce2f.73d5f4dbffab6f6a27f26c6611e32662c98c2891.prepare
babel src -d.

Compilado con éxito 39 archivos con Babel.

[3/5] Recuperando paquetes ...
error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: No se pudo extraer el contenido de tar de indefinido, el archivo parece estar dañado: "ENOENT: no existe tal archivo o directorio, enlace '/ app /.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node '->' /apparn /v6/npm-lz4-0.6.3-78
df6bb69a36d7db6c2e849494876ba6e38e66d6-integration / node_modules / lz4 / build / Release / obj.target / lz4.node '"
info Visite https://yarnpkg.com/en/docs/cli/install para obtener documentación sobre este comando.
info Parece haber problemas con la conexión de red. Reintentando ...

''

Alguien tiene alguna idea de por qué llamaría el hilo

error https://registry.yarnpkg.com/lz4/-/lz4-0.6.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, link '/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/build/Release/lz4.node' -> '/app/.cache/yarn/v6/npm-lz4-0.6.3-
  df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/obj.target/lz4.node'"

cuando el camino correcto debería haber sido:

/app/.cache/yarn/v6/npm-lz4-0.6.3-78df6bb69a36d7db6c2e849494876ba6e38e66d6-integrity/node_modules/lz4/build/Release/lz4.node

parece que el hilo está agregando obj.target/build/Release/ por alguna razón. Podría estar relacionado con https://github.com/yarnpkg/yarn/commit/0e7133ca28618513503b4e1d9063f1c18ea318e5

Estaba recibiendo este mismo error frustrante y difícil de depurar. El problema en mi caso parecía ser el comportamiento de yarn workspace causado por diferentes versiones de la misma dependencia en diferentes paquetes (específicamente ava versiones 2 y 3). Solo una vez que actualicé todas las apariciones de ava a su última versión, dejé de recibir este error.

Estoy ejecutando 1.22.4 y estuve atascado en este problema durante horas. Nuestro monorepo tiene varios módulos usando los mismos paquetes. Finalmente lo ordené aplicando lo siguiente:
1) Asegúrese de usar la misma versión de un paquete en todos los módulos; esto seguramente causará un bloqueo, incluso en devDependencies .
2) Anclar todas las versiones en el monorepo en todos los archivos package.json .

Puede confirmar que todavía hay un problema en 1.22.4 . Originalmente, era mocha , y después de asegurarme de que todos los paquetes usaban la misma versión, ahora recibo errores generados desde camelcase que ni siquiera uso en mi proyecto, aparentemente es de yargs , posiblemente de Lerna.

error Ocurrió un error inesperado: "ENOENT: no existe ese archivo o directorio, lstat '/ code / project / src / packages / private-package / node_modules / camelcase'".

¿Puedo preguntar si hay una solución a la vista? Seguimos eliminando 20 node_modules y un yarn.lock para solucionarlo.

¿Puedo preguntar si hay una solución a la vista? Seguimos eliminando 20 node_modules y un yarn.lock para solucionarlo.

Personalmente, me cambié a lerna con respecto al manejo del espacio de trabajo.

Bastante seguro de que la actual Lerna simplemente pasa a Yarn.

Pude solucionar mis problemas agregando una configuración nohoist para los paquetes de Ember; mi entorno actual está usando una versión anterior de Ember, que es incompatible con los espacios de trabajo.

    "nohoist": [
      "**/ember-package/*ember*",
      "**/ember-package/*ember*/**",
      "**/ember-package/loader.js"
    ]

Creo que tenemos una reproducción mínima aquí ahora: https://github.com/yarnpkg/yarn/issues/7212#issuecomment -637978197

Eliminar yarn.lock luego yarn install funcionó para mí también

¿Alguna noticia aquí? Nuestro proceso de CI simplemente se interrumpió y todas las tuberías fallaron debido a una falla en la instalación de dependencias del hilo. Eso es ridículo.

La configuración de --network-concurrency no soluciona nada y los trabajos se ejecutan en máquinas limpias (sin node_modules, sin yarn .cache).

@cadavre No

yarn set version 2 && yarn config set nodeLinker node-modules

https://yarnpkg.com/getting-started/install#per -project-install
https://yarnpkg.com/configuration/yarnrc#nodeLinker

Esto acaba de empezar a pasarme a mí también, después de actualizar algunas de mis dependencias de vue y firebase. Ahora 100% repetible en mis máquinas de desarrollo y CI. Agregar --network-concurrency 1 no lo soluciona de manera confiable. No me quedo sin espacio en disco ni inodos. Estoy en WSL1. Hilado 1.22.4.

Lo arreglé cambiando temporalmente el directorio de caché, que elimino justo después.

Para mí es la compilación de Docker:

RUN yarn install --check-files --cache-folder .ycache && rm -rf .ycache