Yarn: Paquetes nativos reconstruidos cada vez

No se puede reproducir esto en Mac OSX (10.11.6), por lo que podría ser un problema específico de Ubuntu.

Podría reproducir en Windows 10, pero solo una vez. La segunda vez que ejecuté "yarn", no reconstruyó las bibliotecas nativas. Extraño.

Estaba jugando con él un poco más y se me ocurrieron algunos detalles más:

1. Si ejecuto yarn add leveldown bcrypt , leveldown se compilará como el primer elemento de la lista y el hash en node_modules/.yarn-integrity será igual a 595306... cuando esté terminado (corte por brevedad; supongo que es una suma de verificación que determina si es necesario hacer algo). Ahora, si ejecuto solo yarn nuevamente, ambos paquetes serán reconstruidos y bcrypt se compilará como el primero en la lista (el orden es diferente). La suma de comprobación resultante será igual a cbe480... . La invocación posterior de yarn no reconstruirá los paquetes y la suma de comprobación permanecerá igual. Esto contradice mi informe original (probablemente cometí un error en alguna parte) pero se alinea con lo que estaba viendo @ Daniel15 .
2. Cuando invierto el orden de los paquetes desde el principio ( yarn add bcrypt leveldown ), bcrypt será el primero en la lista y la suma de comprobación resultante será igual a cbe480... inmediatamente. La invocación posterior de yarn no reconstruirá los paquetes.
3. El paquete bcrypt siempre terminará primero (como se esperaba, ya que simplemente no hay mucho que compilar) independientemente de la posición en la lista.

No estoy familiarizado en absoluto con los componentes internos, pero me parece que el orden en el que se compilan los paquetes importa y simplemente no se ordenan cuando se instalan por primera vez (y se ordenan cuando se invoca más tarde yarn ) que afecta la suma de comprobación de alguna manera.

¡Gracias por investigar! Suena como una buena pista. El hash está escrito aquí: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Podría valer la pena depurar ese código y ver qué es diferente en el archivo de bloqueo, ya que el hash en .yarn-integrity se basa en el archivo de bloqueo.

Podría valer la pena depurar ese código y ver qué es diferente en el archivo de bloqueo, ya que el hash en .yarn-integration se basa en el archivo de bloqueo.

Lo sospechaba, pero lo que me desconcertó fue el hecho de que el archivo de bloqueo no cambia, siempre es el mismo. Es solo el hash en .yarn-integration lo que cambia.

$ yarn add leveldown bcrypt
$ cat node_modules/.yarn-integrity
59530680cc0a4ee12feb373980b5abf2edf2fe2aefa16d556bfb531af8299e71
$ cp yarn.lock leveldown_bcrypt_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock leveldown_bcrypt_afterwards.lock
$ diff -s leveldown_bcrypt_initial.lock leveldown_bcrypt_afterwards.lock
Files leveldown_bcrypt_initial.lock and leveldown_bcrypt_afterwards.lock are identical

$ yarn add bcrypt leveldown
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_initial.lock
$ yarn
$ cat node_modules/.yarn-integrity
cbe48058288527f95dfe5643976b0735ee784860663e93ed782b98477c824ec1
$ cp yarn.lock bcrypt_leveldown_afterwards.lock
$ diff -s bcrypt_leveldown_initial.lock bcrypt_leveldown_afterwards.lock
Files bcrypt_leveldown_initial.lock and bcrypt_leveldown_afterwards.lock are identical

$ diff -s leveldown_bcrypt_initial.lock bcrypt_leveldown_initial.lock
Files leveldown_bcrypt_initial.lock and bcrypt_leveldown_initial.lock are identical

Tengo el mismo problema: yo también uso bcrypt. Cada vez que instalo algunos módulos nuevos o actualizo los existentes, tengo que ejecutar npm rebuild para que mi aplicación sea ejecutable.

macOS 10.12 && nodo v7.0.0 && yarn v0.16.1

Ya no puedo reproducir el problema original. Parece haber sido arreglado: +1 :. @ Daniel15 ¿Puedes confirmar?

@hustcer No creo que sea el mismo problema. Es posible que desee probar con la última versión y presentar un nuevo error si aún no le funciona.

@jiripospisil Gracias, está bien ahora después de actualizar a yarn v0.17.4.

Sigo viendo esto, o algo muy similar, en 0.18.1. Por cierto, también es leveldown que se sigue reconstruyendo repetidamente. Usando leftpad como un paquete sin dependencias (y que no depende de leveldown) con fines demostrativos, los pasos de reproducción son los siguientes:

mkdir test && cd test
echo '{ "name": "test", "version": "1.0.0" }' > package.json
yarn add leveldown 
yarn add leftpad
yarn remove leftpad

Mi salida cuando ejecuto esto sigue. Tenga en cuenta que quitar el panel izquierdo lleva casi 40 segundos, la mayoría de los cuales es reconstruir el nivel hacia abajo. Esto sucede de manera consistente, con y sin leveldown o leftpad en la caché de Yarn, aunque solo durante remove y nunca add .

$ mkdir test && cd test
$ echo '{ "name": "test", "version": "1.0.0" }' > package.json
$ yarn add leveldown 
yarn add v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 145 new dependencies.
<... package list omitted for brevity ...>
✨  Done in 49.93s.
$ yarn add leftpad
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
✨  Done in 2.18s.
$ yarn remove leftpad
yarn remove v0.18.1
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
success Uninstalled packages.
✨  Done in 38.76s.
$ yarn why leftpad
<... just to confirm that leftpad and leveldown are entirely unrelated ...>
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.30s.

Versiones:

Nodo v7.3.0
Hilado 0.18.1
OS X El Capitan (10.11.6)

Vuelva a abrir, ya que esto todavía sucede.
Acabo de hacer yarn add redux y reconstruyó bcrypt , node-sass y varios más.

Nodo v6.9.4
Hilado v0.20.3
Windows 10

@seansfkelley Seguí tus pasos con la última versión y funcionó. ¿Podrías intentarlo de nuevo?

/tmp/tp-20170222100611/test ∴ echo '{ "name": "test", "version": "1.0.0" }' > package.json
/tmp/tp-20170222100611/test ∴ yarn add leveldown
yarn add v0.20.3
info No lockfile found.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 54 new dependencies.
<cut>
warning [email protected]: No license field
✨  Done in 1.64s.
/tmp/tp-20170222100611/test ∴ yarn add leftpad
yarn add v0.20.3
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
└─ [email protected]
warning [email protected]: No license field
✨  Done in 0.69s.
/tmp/tp-20170222100611/test ∴ yarn remove leftpad
yarn remove v0.20.3
[1/2] Removing module leftpad...
[2/2] Regenerating lockfile and installing missing dependencies...
warning [email protected]: No license field
success Uninstalled packages.
✨  Done in 0.66s.
/tmp/tp-20170222100611/test ∴ yarn why leftpad
yarn why v0.20.3
[1/4] 🤔  Why do we have the module "leftpad"...?
[2/4] 🚚  Initialising dependency graph...
warning [email protected]: No license field
[3/4] 🔍  Finding dependency...
error We couldn't find a match!
✨  Done in 0.20s.

@Nexxado ¿Podrías agregar algunos pasos de reproducción? Probé algunas combinaciones pero funcionó.

Nodo 7.3.0
Hilado 0.20.3
MacOS 10.12.3

@jiripospisil No tengo pasos de reproducción que proporcionar, simplemente instalar un paquete adicional hace que el hilo se vincule y reconstruya todo.

Aquí está el resultado de agregar un paquete (el archivo de bloqueo ya existe):

Vinculación de dependencias:

Reconstrucción:

@jiripospisil También sigo viendo esto, pero durante mi reproducción me tropecé porque parece que leveldown (o una dependencia del mismo) puede haber comenzado a enviar un binario compatible con OS X, por lo que los tiempos de instalación cayeron sospechosamente de 50 a 3 segundos. Si está en OS X y específicamente yarn add [email protected] lugar de solo yarn add leveldown , debería ver el mismo comportamiento que antes.

Tengo una dependencia indirecta de ttf2woff2 , que también se reconstruye cada vez.

Sin embargo, solo se reconstruye cada vez que hay un cambio en yarn.lock . Es decir, yarn con un nuevo yarn.lock , yarn upgrade , yarn upgrade-interactive . En el caso yarn upgrade-interactive , si tanto los devdeps como los deps regulares se actualizaron, ttf2woff2 se reconstruye dos veces (!).

También veo este problema, aunque no pude reproducirlo con los pasos anteriores. Sin embargo, puedo reproducirlo con estos pasos:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

hilo añadir co
''

luego de nuevo se construye leveldown.

No parece importar qué paquete agregue, siempre se reconstruye a nivel inferior.

Estoy usando Yarn v0.21.3, Windows 10 y Node v7.7.1

Yo también veo esto. Estoy usando BuckleScript (bs-platform) ....

También me encuentro con este problema con sharp . Cada vez que ejecuto yarn add o yarn remove , sharp se reconstruyen, incluso con paquetes no nativos.

Probado en yarn v0.21.3, Node 7.0.0, bajo Windows 10 y Ubuntu Linux 16.04.

Aquí están las dependencias de package.json , si ayuda:

{
  "devDependencies": {
    "auto-reload-brunch": "^2.7.1",
    "babel-brunch": "^6.1.1",
    "babel-preset-env": "^1.2.1",
    "brunch": "^2.10.8",
    "chai": "^3.5.0",
    "clean-css-brunch": "^2.10.0",
    "css-brunch": "^2.10.0",
    "express-mysql-session": "^1.2.0",
    "javascript-brunch": "^2.10.0",
    "jquery": "^3.1.1",
    "less-brunch": "^2.10.0",
    "mocha": "^3.2.0",
    "nodemon": "^1.11.0",
    "npm-run-all": "^4.0.2",
    "postcss-brunch": "^2.0.5",
    "postcss-cssnext": "^2.9.0",
    "postcss-font-magician": "^1.6.1",
    "uglify-js-brunch": "^2.10.0"
  },
  "dependencies": {
    "body-parser": "^1.17.1",
    "connect-redis": "^3.2.0",
    "cookie-parser": "^1.4.3",
    "debug": "^2.6.1",
    "express": "^4.15.2",
    "express-session": "^1.15.1",
    "jstransformer-marked": "^1.0.2",
    "md5": "^2.2.1",
    "morgan": "^1.8.1",
    "multer": "^1.3.0",
    "node-mysql": "^0.4.2",
    "passport": "^0.3.2",
    "passport-local": "^1.0.0",
    "pug": "^2.0.0-beta11",
    "serve-favicon": "^2.4.1",
    "sharp": "^0.17.2"
  }
}

también viendo esto con bs-platform

También experimentando esto con ttf2woff2 cada llamada a yarn add reconstruye ttf2woff2 aunque no se haya publicado en más de un año.

También tengo esto con sofabase

editar: parece estar arreglado en 0.23.2

Todavía me sucede en 0.23.2 ( argon2 y node-sass se reconstruyen cada vez que agrego / elimino algún paquete no relacionado como moment que no tiene dependencias)

SO: Windows 10
Nodo: 7.9.0
Hilado: 0.23.2

Para agregar un poco más de color, mi percepción de que esto sucediera en yarn add <some-package> fue mucho mayor que la realidad, ya que muchos casos para mí se desencadenaron al combinarlos con yarn remove <unrelated-package> inmediatamente antes debido al force: true en esta línea .

Ciertamente es conveniente reutilizar la lógica de instalación en remove para generar el archivo de bloqueo, pero sería bueno si no viniera con todo el equipaje de una instalación forzada :)

Para mí, esto comenzó a suceder nuevamente cuando actualicé a 0.23.x. Volví a 0.21.3 y ya no se construye cada vez. Además, esto llevó a este problema en el que unicode.org bloqueó mi IP después de actualizar algunos paquetes seguidos https://github.com/dodo/node-unicodetable/issues/16

Si bien 0.21.3 no reconstruye todos los paquetes al agregar un nuevo paquete, reconstruye todos los paquetes al quitarlo. Y parece que el hilo no considera un fracaso si la reconstrucción falla.

Para mí, la degradación a 0.21.3 no ayudó. bs-platform se reconstruye en cada adición / eliminación.

Viendo esto en macOS con Yarn 0.23.4. Reconstruye sqlite3 cada vez que ejecuto yarn add .

$ yarn add gulp-rename gulp-notify gulp-sass -D                                                                                         1 ↵
yarn add v0.23.4
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The platform "darwin" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 42 new dependencies.
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
└─ [email protected]
$ install-app-deps
Rebuilding native production dependencies for darwin:x64
Rebuilding native dependency sqlite3
✨  Done in 56.61s.

Viendo este problema con Ubuntu 16.04LTS, con el último yarn v0.24.6, con el nodo 8.1.2

Veo la reconstrucción de gdal , node-sass cada vez que agrego un módulo, esto hace que la adición de hilo tarde más de lo necesario en ejecutarse.

También estoy viendo esto, es muy molesto en una Raspberry Pi Zero W donde la creación de paquetes (como bleno) puede llevar varios minutos.

Sigo viendo esto con Yarn v0.27.5 y uws . Cada vez que cambia algo en mis paquetes, se reconstruye uws.

Lo único interesante que puedo ver sobre uws es que no tiene un campo de dependencias en package.json .

Esto se ha convertido en una gran frustración para mí en los últimos días. Tenía windows-build-tools instalado globalmente en una etapa (realmente solo necesita construirse una vez para configurar el entorno de desarrollo de Windows para paquetes nativos) que se reconstruía cada vez que agregué un paquete. Como puede imaginar, eso tomó bastante tiempo y finalmente me di cuenta de que ya no necesitaba instalarlo y lo eliminé.

Ahora parece que node-sass sigue queriendo reconstruir en otro proyectado al agregar paquetes.

Este comportamiento ocurre tanto en yarn add como en yarn remove para mí. Seguramente no es necesaria una reconstrucción para estos pasos, ya que los paquetes nativos solo se compilan una vez según la versión de Nodo.

Editar: usando Node v8.2.1 y Yarn v0.27.5 en Windows 10.

No puedo contar las veces que uws fue reconstruido para mí :) Tenga en cuenta que uws
tiene cero dependencias e incluso le falta el campo en package.json

El lunes, 31 de julio de 2017, 10:50 p.m. Paul Myburgh [email protected]
escribió:

Esto se ha convertido en una gran frustración para mí en los últimos días. tuve
Windows-build-tools instaladas globalmente en una etapa (solo necesita realmente
construirse una vez para configurar el entorno de desarrollo de Windows para
paquetes) que seguía reconstruyéndose cada vez que añadía un paquete. Como
puedes imaginar que tomó bastante tiempo y finalmente me di cuenta de que no
lo necesito instalado más y lo quitó.

Ahora parece que node-sass sigue queriendo reconstruir en otro proyectado
al agregar paquetes.

Este comportamiento ocurre tanto en la adición de hilo como en la eliminación de hilo para mí. Seguramente no
La reconstrucción es necesaria para estos pasos ya que los paquetes nativos solo se compilan
una vez según la versión Node?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

Estoy en 0.27.5 y sigo viendo este comportamiento con bs-platform .

Es una gran frustración esto, lo mismo ocurre con bs-platform .

Buen sentido de derecho allí ... ¿Qué tal un PR Tim?

El martes 22 de agosto de 2017 a las 10:44 a.m. Tim Shnaider [email protected]
escribió:

FFS, ¿se puede arreglar esto?
Al menos proporcione una opción de línea de comando o una configuración env para deshabilitarlo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

No parece que se haya mencionado hasta ahora, pero también puedo reproducir este error con yarn global list .

Pasos para reproducir:

1. Use un entorno global nuevo:: advertencia: ejecute esto solo si sabe lo que está haciendo

   rm -rf ~/.config/yarn/
   

2. Agregue un paquete problemático (_i.e._ zeppelin-solidity ):

   → yarn global add node-gyp zeppelin-solidity
   yarn global v0.27.5
   [1/4] Resolving packages...
   warning zeppelin-solidity > truffle-hdwallet-provider > web3-provider-engine > ethereumjs-block > merkle-patricia-tree > level-ws > xtend > [email protected]:
   [2/4] Fetching packages...
   [3/4] Linking dependencies...
   [4/4] Building fresh packages...
   success Installed "[email protected]" with binaries:
         - node-gyp
   warning "[email protected]" has no binaries
   Done in 20.53s.
   

3. Ejecute yarn global list y vea cómo se vuelven a compilar algunos paquetes nativos

4. Repita todo lo que quiera, yarn global list siempre recompilará esos paquetes nativos
5. 😭

Espero que esto ayude.

ℹ️ MacOS 10.12.6 con Yarn 0.27.5 instalado a través de Homebrew.

El derecho es innecesario, pero puedo entender la frustración. Esto está haciendo perder mucho tiempo a mucha gente (las reinstalaciones largas se acumulan con el tiempo y rompen el flujo). Claro, puede decir "hacer una solicitud de extracción", y eso es justo. Pero sería un proceso de aprendizaje además de cambiar potencialmente solo unas pocas líneas de código ... Lo que esperamos es que las personas que conocen los entresijos de este proyecto puedan priorizar este tema en la próxima versión, ya que realmente parece bastante importante (¿y potencialmente una solución fácil? Evite reinstalar binarios si la versión de Node no ha cambiado tal vez).

Ha pasado casi un año desde que se informó por primera vez.

Espero no parecer legítimo al decir eso ... Me gustaría agregar que estoy muy agradecido por este proyecto y la utilidad que ya me brinda. Este problema ha sido uno de los pocos puntos débiles que he tenido.

EDITAR: Acabo de hacer un yarn remove para un paquete aleatorio y lo intentó y (esta vez) no pudo reconstruir mis binarios. El efecto secundario es que mis binarios faltan por completo ahora y parece que la única forma de solucionarlo es con un npm rebuild . Entonces, no solo parece que este problema causa reconstrucciones innecesarias, sino que si falla ese proceso, parece que tiene que volver a recurrir a npm para solucionarlo nuevamente.

Veo el mismo comportamiento que @zhangjyr y @lostpebble. Ejecutar yarn add funciona bien pero yarn remove hace que los paquetes nativos se reconstruyan.

Mac Sierra 10.12.6
Hilado 0.27.5

Trataré de ver qué puedo hacer al respecto, ya que esto también me afecta. Dicho esto, no es tan difícil contribuir a Yarn, así que si alguien quiere enviar un PR, por favor inténtelo y trataremos de apoyarlo tanto como podamos.

No podré trabajar en esto durante algunas semanas.

Yo también estoy viendo esto.
Trabajando en la construcción del sitio en gatsby. CUALQUIER operación de hilo causa reconstrucción.
Intente crear un sitio con gatsby e hilar con él. Espero que esto ayude

Viendo esto en un proyecto usando gatsby:
hilo 1.0.2
nodo 7.10.1
ubuntu 16.04

Este problema se está volviendo bastante serio ahora. No solo mis binarios siempre se reconstruyen. Pero a menudo sucede que mis binarios se eliminan por completo después de yarn add o yarn install (después de cambiar los números de versión de un paquete en package.json para actualizar / deshacer un módulo). Y no importa cuánto ejecute yarn install o yarn install --check-files después, esos binarios simplemente se pierden y desaparecen y nunca vuelven. La única forma de recuperarlos es con npm rebuild .

Empieza a parecer que el hilo no tiene ningún conocimiento sobre el estado de los paquetes nativos. Si ya están instalados / construidos, o si no están instalados / construidos correctamente.

¿Ha habido quizás algún progreso en esto?

Creo que la reciente adición de campo artifacts al archivo de integridad del hilo por @arcanis ayudaría a solucionar este problema. Sin progreso todavía, pero abierto a RP :)

Tengo un problema similar con la plataforma bs al instalar paquetes en mi proyecto de whyml

Lo mismo ... literalmente, cada yarn add reconstruirá el proyecto gyp.

También sucede aquí.
(hilo 1.2.1)

Veo esto con node-sass .

Sucede que me encuentro con Cypress, por ejemplo.

nodo -v
v8.8.1
hilo -v
1.2.1

✋ En lugar de escribir "Yo también" sin información adicional, use la función +1 en Github en la publicación superior . Cada vez que escribe un comentario "yo también", 35 suscriptores son notificados innecesariamente.

+1

Simplemente haga clic en Subscribe si desea recibir actualizaciones. Espero que todos quieran ser notificados cuando se resuelva, pero no cuando alguien nuevo se enfrente a este problema también.

@BYK , ¿puede bloquear el hilo y hacerlo disponible solo para los propietarios?

Actualmente estoy investigando este problema y tratando de reducirlo a un caso de prueba mínimamente reproducible. Un paquete "excelente" para demostrar este problema es htmlstrip-native ; se tarda unos minutos en compilar, por lo que no se lo puede perder.

Me encantaría que alguien más probara este package.json en una carpeta vacía:

{
  "name": "yarn-test",
  "version": "1.0.0",
  "dependencies": {
    "htmlstrip-native": "^0.1.3",
    "left-pad": "1.1.3"
  }
}

Intente ejecutar estos comandos:

yarn
yarn upgrade [email protected]

En mi máquina, con el último hilo 1.2.1, el comando upgrade da como resultado una reconstrucción de htmlstrip-native que lleva una eternidad. Yarn no debería estar reconstruyendo esto ya que actualizar left-pad no tiene ningún efecto en htmlstrip-native o sus dependencias.

Ahora prueba npm :

rm -rf node_modules
npm install
npm install [email protected]

En mi máquina, el segundo comando (correctamente) no da como resultado una nueva reconstrucción de htmlstrip-native .

EDITAR : Al volver a leer todas las publicaciones anteriores, parece que este caso no sorprenderá a nadie: la mayoría de las personas, incluido yo mismo, están descubriendo que simplemente pedirle a Yarn que haga _cualquier cosa_ resulta en una reconstrucción. Supongo que este no es un problema mayor en la comunidad porque la mayoría de las personas no usan paquetes nativos que tardan mucho en compilarse, por lo que no tienen un paso de reconstrucción o termina tan rápido que a quién le importa.

Bien, luego de mucha depuración, parece que este comportamiento es intencional. Al rastrear el código, parece que, por ejemplo, yarn upgrade [email protected] da como resultado los siguientes pasos:

1) Se llama al módulo upgrade , que ejecuta una operación new Add() para left-pad .
2) Add.init() llama a su superclase, Install.init()
3) Install.init() pone en cola un paso de rebuildingPackages
4) En PackageInstallScripts.init() simplemente recolecta _todos_ los paquetes y los agrega al workQueue para ser reconstruidos.
5) PackageInstallScripts luego descubre que hay un comando de instalación para htmlstrip-native y simplemente lo ejecuta: esta es la reconstrucción nativa súper lenta que todos estamos viendo.

De todo lo que he visto hasta ahora, parece que no hay lógica que pretenda filtrar los paquetes que no "necesitan" ser reconstruidos. Simplemente está reconstruyendo todo, como se indica en la salida de la consola.

Me encantaría que alguien del equipo de Yarn intervenga aquí; si este comportamiento es realmente intencional, ¡recomendaría cerrar este problema!

Para mi situación personal, simplemente voy a cambiar mi dependencia htmlstrip-native ya que no hay ninguna razón por la que deba tardar minutos en construirse (es como, un par de pequeños archivos .c ). El resto de mis departamentos nativos se construyen rápidamente, por lo que no es un gran problema si sucede todo el tiempo.

Suena como un efecto secundario involuntario del diseño, pero tal vez alguien en @ yarnpkg / core pueda comentarlo. No creo que esté destinado a reconstruir paquetes que no necesitan ser reconstruidos.

Esto no es intencional, probablemente sea más fácil de implementar de esa manera.
Hay un comentario anterior de BYK que dice que este problema está buscando un PR:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Ciertamente, los paquetes nativos pesados ​​no son lo suficientemente comunes como para aparecer como la prioridad más alta para Yarn, sin embargo, Yarn tiene la capacidad de no reconstruir paquetes en cada instalación.
Esto parece un error que debería ser fácil de solucionar, envíe un PR.
Puede haber advertencias porque Yarn no puede saber con certeza si un paquete construido podría haber sido dañado, por eso está volviendo a ejecutar ansiosamente los scripts de instalación ahora.

Hay una bifurcación de Yarn que utiliza el equipo detrás de Reason https://github.com/esy-ocaml/esy-install que soluciona muchos problemas de compilación nativa porque las dependencias de Reason / Ocaml requieren una compilación pesada.
A medida que ese enfoque madura, espero que sea posible fusionar los cambios en sentido ascendente.

Entonces, fundamentalmente, los paquetes nativos se reconstruyen porque:

1) Se ha establecido la bandera force=true , o
2) El paquete ha sido marcado como fresh=true .

Parece que con algunos comandos (como upgrade y remove ), el indicador force se establece en verdadero "por si acaso". Esta bandera promete "reconstruir todos los paquetes independientemente de si han cambiado", por lo que no tiene sentido agregar algún código de detección de cambios porque eso rompería esta promesa.

Entonces, para solucionar esto, parece que tendremos que desafiar las suposiciones de los distintos lugares del código que establecen force=true .

El primero que rastreé ocurre cuando se ejecuta yarn upgrade whatever . Fue introducido en este compromiso como parte de # 2780 por @juanca. Las notas de confirmación dicen:

"Ensure force flag is enabled when using `yarn upgrade` Otherwise exotic packages are not updated."

¿Quizás @juanca o alguien más familiarizado con la historia del hilo podría intervenir con el problema que se pretendía resolver?

@nfarina gracias, eso aporta claridad. Para las actualizaciones, quizás realmente queramos forzar la construcción de paquetes nativos (si se están actualizando). Pero para las instalaciones (agregar hilo), diría que legítimamente necesitamos desafiar, como dijiste, la suposición que hace que los paquetes nativos ya instalados se reconstruyan cuando se instala algo más.

Supongo que la bandera force está configurada para que el solucionador de Yarn no omita la dependencia existente porque la versión anterior está en yarn.lock.

Creo que fue una solución rápida para que la actualización funcione.
Una forma adecuada sería pasar otra bandera que afecte solo la resolución de paquetes específicos y que no sea tan nuclear como force .
Envíe un PR :)

¿Quizás @juanca o alguien más familiarizado con la historia del hilo podría intervenir con el problema que se pretendía resolver?

Correcto, estaba trabajando solo con la API Add ; no hace (¿hizo?) Nada al agregar un paquete existente.

También recomiendo usar una mejor técnica para controlar el flujo del procedimiento.

Estoy usando hilo en mi raspberry pi zero en un proyecto que tiene una dependencia de node-opencv. Cada vez que agrego / elimino / actualizo un paquete no relacionado, tengo que esperar 35 minutos para la reconstrucción.

@ Torsten85 , también lo uso en pi, sí, las reconstrucciones innecesarias es algo que debemos abordar.
¿Puede proporcionar un script de reproducción para sus reconstrucciones?

lo mismo aquí, en lubuntu 17.10, cuando uso hilo, desarrollando con https://github.com/mui-org/material-ui

cada yarn add/remove (-D) <pkg> reconstruir todo, como una nueva instalación, lleva más de 1 minuto

¿Es así como lo maneja npm también? Si no, ¿sería una posible solución cambiar temporalmente?

está pasando también por aquí

• nodo 9.2.0
• hilo 1.4.0

cada vez que agrego alguna dependencia, los módulos como bcrypt o couchbase se reconstruyen cada vez

Hola a todos, estoy trabajando en un pequeño truco https://github.com/yarnpkg/yarn/pull/5314.
La idea es almacenar en caché un paquete integrado en un espejo sin conexión para evitar ejecutar scripts de instalación todo el tiempo.

Entonces, si usa offline-mirror y ejecuta yarn add node-sass :

1. yarn compilaría e instalaría node-sass como de costumbre,
2. después de ejecutar los scripts de instalación, generará node-sass-v4.7.2-darwin-x64-57.tgz de la carpeta node_modules/node-sass modificada
3. La próxima vez que ejecute yarn install en la misma plataforma, simplemente descomprimirá node-sass-v4.7.2-darwin-x64-57.tgz lugar del original y no ejecutará los scripts de instalación

Esto no funcionará en todos los casos, pero podría ser una solución para los sistemas de CI fuera de línea en los que no desea que los paquetes lleguen a Internet y ejecuten los mismos scripts de instalación cada vez.

Estoy intentando instalar mecanografiado como paquete global, y Yarn pasa todo el tiempo reconstruyendo cosas en lugar de instalar lo que realmente necesito ahora.

Pasé al hilo pensando que es más rápido y mejor. Eliminé cualquier rastro de npm (excepto lo que viene con la instalación del nodo); y reinstaló todos los paquetes globales a hilo.

Yarn ahora está poniendo a prueba mi paciencia al hacerme esperar de 1 a 15 minutos para la instalación simple del paquete. Yarn debería ser lo suficientemente inteligente como para instalar lo que se solicita primero antes de reconstruir otras cosas, a menos que el paquete solicitado dependa explícitamente de cualquiera de los paquetes nativos que requieran reconstrucción.

Medio ambiente:

• Nodo: 9.4.0
• Hilado (global): 1.3.2
• macOS Sierra: 10.12.6
• Macbook pro de 15 pulgadas
  
  
  
  • Memoria: 16 GB
  
  
  • CPU: 2 GHz - Intel Core i7
  
  
  • Almacenamiento: magentic (mucho espacio libre)
  
  
  • Aplicaciones que se ejecutan en el momento de la instalación: Firefox (6 pestañas), Mail.app e iTerm (con 2 pestañas)
  
  

Registros

Obtener paquetes lleva mucho tiempo

Mecanografiado de actualización global de hilo
hilo global v1.3.2
[1/4] 🔍 Resolviendo paquetes ...
[2/4] 🚚 Obteniendo paquetes ...
[############################################### ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

La vinculación de dependencias se bloquea sin ningún progreso durante minutos

Mecanografiado de actualización global de hilo
hilo global v1.3.2
[1/4] 🔍 Resolviendo paquetes ...
[2/4] 🚚 Obteniendo paquetes ...
[3/4] 🔗 Vinculando dependencias ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

Reconstruir todos los paquetes: lleva mucho tiempo

Mecanografiado de actualización global de hilo
hilo global v1.3.2
[1/4] 🔍 Resolviendo paquetes ...
[2/4] 🚚 Obteniendo paquetes ...
[3/4] 🔗 Vinculando dependencias ...
[4/4] 📃 Reconstruyendo todos los paquetes ...
[17/12] ⠐ websocket
[2/17] ⠐ expresso: verificando la opción gcc para aceptar ISO C99 ...
[17/8] ⠐ puerto serie: utilizando [email protected] | darwin | x64
[17/6] ⠐ ahora:> Para obtener el código fuente, consulte: https://github.com/zeit/now-cli

Mecanografiado de actualización global de hilo
hilo global v1.3.2
[1/4] 🔍 Resolviendo paquetes ...
[2/4] 🚚 Obteniendo paquetes ...
[3/4] 🔗 Vinculando dependencias ...
[13/17] ⠈ sin servidor
[13/17] ⠂ sin servidor
[14/17] ⠠ solgrafo
[14/17] ⠁ solgrafo
[14/17] ⡀ solgrafo
[- / 17] ⠈ esperando ...
[- / 17] ⠄ esperando ...
[- / 17] ⠠ esperando ...
[- / 17] ⠈ esperando ...
[- / 17] ⠄ esperando ...
[- / 17] ⢀ esperando ...
[- / 17] ⠈ esperando ...

Sigo esperando :-)

Otro efecto secundario es que las bibliotecas que descargan y almacenan en caché las precompilaciones también se borran y deben descargarse de nuevo: es decir, la caché de nwjs-builder-phoenix de sdks de destino de compilación

1. El paquete nativo siempre se reconstruye cuando se actualiza una versión de paquete que no es un paquete nativo.

¿Yarn almacena el binario en el global como npm?

Empieza a frustrarme un poco tener que reconstruir nwjs en cada instalación simple. No tiene sentido

También estoy viendo esto. uws se reconstruye cada vez que hago una operación de agregar / quitar. hilo v1.3.2

Hola @bestander. Probamos # 5314 en monorepo de nuestra empresa, sin embargo, no tuvo ningún efecto en detener las reconstrucciones de algunas dependencias para nosotros. Hemos habilitado yarn-offline-mirror y pack-built-packages en .yarnrc como se muestra en las pruebas agregadas.

El quid es que ejecutar yarn siempre nos toma alrededor de 40-50 segundos, incluso si el comando que ejecutamos directamente antes era yarn también.

@ bazyli-brzoska, cambié la bandera para que sea más explícita y olvidé actualizar la descripción.
¿Puedes probar con la bandera experimental-pack-script-packages-in-mirror establecida como "verdadera"?

¿Hay algún progreso en esto? Veo que la solicitud de extracción ya está fusionada y que está en la última versión 1.5.1. Estoy en 1.5.1 y nada cambió para mí. Sin embargo, estoy considerando volver a npm, porque espero 322.70s o 282.69s o incluso 683.41s (estos son realmente mis últimos tres yarn add s) por instalar un pequeño complemento acumulativo o lodash o bueno, prácticamente cualquier cosa, es una locura.

Sería fantástico si importantes advertencias como estas estuvieran en su archivo README.md. Los usuarios instalan hilo porque supuestamente es "más rápido" y hacer esta transición de npm a hilo no es un paso pequeño, por lo que sería bueno si hubiera alguna advertencia anticipada para los desarrolladores, para que puedan pensarlo una vez más, antes de convertir sus escrituras, contaminando sus globales y aprendiendo el hilo cli.

Pensé que esto era solo un problema con mi vieja máquina de 32 bits, pero después de verlo por 237a vez, lo busqué en Google y, oh, el hilo no es más rápido. Excelente.

Probablemente lo siento por ser malo, pero creo que te sientes frustrado.

Aceptamos contribuciones.

Dicho esto, algo a tener en cuenta con respecto a los paquetes que se reconstruyen cuando no "necesitan": los pasos de compilación se ejecutan después de instalar las dependencias. Lo que significa que los scripts de compilación pueden usar esas dependencias. Lo que significa que si estas dependencias cambian por cualquier motivo (lo que podría ocurrir 'aleatoriamente', por ejemplo, si optimizamos dos versiones compatibles de un paquete en una), entonces realmente necesitamos volver a ejecutar los pasos de compilación incluso si esas dependencias no son realmente utilizado durante la construcción (porque ¿cómo podríamos saberlo?).

Entonces no es exactamente un problema fácil. Al menos parte del problema proviene del propio diseño de package.json. Háblame de la frustración 🙂

@arcanis no entiendo esta parte:

incluso si esas dependencias no se usan realmente durante la compilación (porque ¿cómo podríamos saberlo?).

Pensé que el diseño de YARN era mantener las dependencias estáticas + versión (bloqueo de hilo) y así no habrá "actualizaciones" aleatorias.
Aunque, el paquete json da un árbol completo, entonces ¿por qué dice "cómo podríamos saberlo"? Una vez que se resuelve el árbol, es muy fácil decir si alguna de las dependencias (incluso las de nivel profundo) para construir X cambió o no.

Digamos que tengo una dependencia foo que depende de babel-core y left-pad@^1.0.0 , y que esta dependencia foo tiene un script de compilación que ejecuta babel en su archivo de índice .

Después de ejecutar yarn add foo en la carpeta de mi proyecto, termino teniendo [email protected] en node_modules, ¿verdad? Ahora digamos que se lanza una nueva versión del panel izquierdo ( 1.1.0 ) y quiero usarla en mi proyecto. Ejecutaré yarn add left-pad , que luego se resolverá en latest , es decir, 1.1.0 .

Ahora, lo que puede suceder es que Yarn "verá" que hay dos copias del pad izquierdo en el árbol, y también verá que se pueden optimizar: después de todo, foo depende de left-pad@^1.0.0 , entonces 1.1.0 es compatible. Por lo tanto, eliminará la versión anterior y solo usará 1.1.0 . Debido a que la dependencia cambió, necesitamos ejecutar el script de compilación nuevamente porque Yarn no tiene forma de saber que left-pad es una dependencia de tiempo de ejecución en lugar de una dependencia de tiempo de compilación .

Ahora podría preguntar "pero ¿por qué no simplemente omitir la reconstrucción cuando las dependencias transitivas cambiaron?". La respuesta es que algunos paquetes (en particular los paquetes nativos) tienen dependencias que afectan radicalmente la forma en que se construyen. Cuando sucede, realmente, realmente queremos reconstruir esos paquetes, o terminaríamos con artefactos incompatibles.

@arcanis , creo que no entiendes el problema. el problema aquí es que estos paquetes nativos se están reconstruyendo _ cada_ vez, incluso cuando yarn se ejecuta dos veces (o más) en rápida sucesión. no tiene nada que ver con la actualización de las dependencias, siempre se reconstruye.

@Spongman Estoy de acuerdo con tu último comentario. Pero como @Spongman mencionó correctamente, la reconstrucción ocurre todo el tiempo . Incluso si solo hace yarn && yarn , obtiene dos reconstrucciones completas , a pesar de que nada cambió en la estructura de dependencia.

Intenté ejecutar yarn add leveldown bcrypt && yarn && yarn como en el OP y solo obtuve una compilación: / ¿Tiene un comando que pueda usar para reproducir este comportamiento?

Puedes probar, por ejemplo:

mkdir foobar
cd foobar
yarn init
....
yarn add socket.io
      (5 native packages build)
yarn add react
      (5 native packages build again)
yarn remove react
      (5 native packages build again)

(esto es bajo Ubuntu 14 LTS)

foobar billli$ yarn -v
1.3.2
foobar billli$ node -v
v8.9.1

yarn & yarn 

No está causando dos reconstrucciones, pero el ejemplo con socket.io, agregando react, eliminando react está causando dos reconstrucciones

Probé el ejemplo de socket.io con yarn v1.5.1 y no obtuve reconstrucciones cuando usé la nueva función para almacenar en caché las compilaciones nativas. Para hacer eso, necesita usar el caché sin conexión. En mi ~/.yarnrc tengo:

experimental-pack-script-packages-in-mirror true
pack-built-packages true                                         
yarn-offline-mirror "/home/skomorokh/yarn-offline-cache"

Cuando intento como otro usuario sin esa configuración, todavía se reconstruye cada vez.

Sí, no reconstruir ahora cuando se agregan estas opciones.
Pero si solo experimental-pack-script-packages-in-mirror true , aún se reconstruye.
¿Por qué no establecer yarn-offline-mirror en una ruta predeterminada como "~ / .yarn / cache"?

Aún experimental, pero es una sugerencia interesante (cc @bestander). Supongo que el problema que tengo con esto es que personalmente no me gusta la idea de habilitar cosas sin el consentimiento explícito del usuario. También tiene otras implicaciones: ¿qué significaría tener yarn-offline-mirror establecido en false , y experimental-pack-script-packages-in-mirror en true ? ¿Debería experimental-pack-script-packages-in-mirror sobrescribir la configuración de yarn-offline-mirror ? Un poco confuso en mi opinión.

Dicho esto, el error de reconstruir uws al agregar left-pad es un poco molesto, y la configuración de experimental-pack-script-packages-in-mirror solo es una solución. No estoy seguro de tener el ancho de banda para ver esto en la próxima semana, pero si alguien está interesado en obtener una solución, sería bastante impactante.

@arcanis Gracias por la amable respuesta. La frustración proviene de la forma en que se presenta el hilo. Por el momento, simplemente no es "rápido", definitivamente no es más rápido que npm y es algo inutilizable en proyectos del mundo real. En mi humilde opinión, debería haber información sobre esto o incluso la solución alternativa de @skomorokh en su archivo README.md hasta que se solucione. O simplemente elimine el "rápido" de su descripción.

Sentiría la misma frustración si el archivo Léame del repositorio de angularjs indicara que es un marco ligero. Simplemente no lo es.

Siempre se repite para descargar el archivo binario después de yarn-offline-mirror config.

cd \tmp\t
yarn init
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node
yarn add node-sass
Donwnloading Binary from: https://github.com/sass/node-sass/releases/download/v4.7.2/linux-x64-57_binding.node

Voy a intentar depurarlo un poco hoy. Creo que en realidad podría ser tan simple como PackageInstallScripts no marcar pkg.fresh solo para reconstruir los paquetes recién instalados. En lugar de eso, parece que solo los recorre a todos.

Después de jugar un poco, empiezo a pensar que reconstruimos las cosas todo el tiempo en caso de que alguien rm -rf node_modules o el módulo se elimine de allí.

Tenemos una lista de artefactos de compilación detectados en el archivo .yarn-integrity , así que estoy pensando que una reconstrucción solo debería ocurrir si fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

Así que es un poco más complicado de lo que pensaba.

Acabo de yarn add ed moment , un paquete de dependencia cero, para mi aplicación de reacción actualizada, tomó 377.97s .

Lo hice de nuevo justo después de eso, tomó 389.63s y reconstruyó los binarios nuevamente.

Solo para comparar, luego eliminé node_modules e ingresé npm install :
added 1751 packages and updated 124 packages in 360.595s

Cambiado de nuevo a npm ahora.

OK, más información para todos los ojos sobre este tema ... He estado jugando con esto durante un día y medio y finalmente me di cuenta de algunas cosas.

Primero, la mayoría de estos problemas de reconstrucción están solucionados. Ya hay un código en PackageInstallScripts que solo vuelve a ejecutar los scripts de instalación de un paquete si está marcado como "nuevo" :

    if (!ref.fresh && !this.force) {
      // this package hasn't been touched
      return false;
    }

Entonces, por ejemplo, si usa node-sass :

yarn add node-sass <-- builds sass because first install
yarn add left-pad <-- does NOT rebuild node-sass

Además, los yarn install s consecutivos no se reconstruyen.

yarn add uws <-- builds because first install
rm -rf node_modules
yarn install <-- builds uws because dir was deleted
yarn install <-- does NOT rebuild uws

... pero, por supuesto, hay un par de excepciones ...

En un yarn remove la bandera force está configurada (para corregir algún otro error, supongo, pero ha sido así durante> 2 años), por lo que las reconstrucciones siempre ocurren.

Sin embargo, esto es posiblemente "correcto" porque es lo que npm también hace:

~/Projects/yarn-test 🐒   npm uninstall left-pad

> [email protected] install /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/install.js

Cached binary found at /Users/me/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> [email protected] postinstall /Users/me/Projects/yarn-test/node_modules/node-sass
> node scripts/build.js

Binary found at /Users/me/Projects/yarn-test/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

added 180 packages, removed 1 package and updated 7 packages in 4.03s

Puede ver que en uninstall de left-pad , npm ejecutó los scripts install y postinstall para node-sass .

El paquete uws (que es utilizado por muchos otros paquetes, como socket.io , browser-sync , etc.

algo durante el proceso de instalación cambia uno de los archivos (el tamaño y la marca de tiempo son diferentes).

~/Projects/yarn-test 🐒   ls -l /Users/me/Library/Caches/Yarn/v1/npm-uws-9.14.0-fac8386befc33a7a3705cbd58dc47b430ca4dd95/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  383636 Nov 21 00:43 uws_darwin_57.node

~/Projects/yarn-test 🐒   ls -l node_modules/uws/uws_darwin_57.node
-rwxr-xr-x  1 me  891112136  378672 Mar  4 11:18 uws_darwin_57.node

yarn ve un archivo que ha "cambiado" en comparación con el caché, por lo que marca el paquete como "nuevo" para volver a instalarlo

Esto luego activa la lógica anterior que vuelve a ejecutar los scripts de instalación porque es "nueva". Yarn está tratando de ser útil y "arreglar" los archivos incorrectos, pero por supuesto no sabe que el archivo cambió debido al script de instalación. Es posible que tengamos que investigar alguna forma de solucionar este problema, pero también se habla de cambiar la forma en que se comparan estos archivos (deje de ejecutar estadísticas en cada archivo), por lo que podría resolverse con esa revisión.

Con suerte, eso explica algunos de los casos aquí en los que algunas personas dicen que funciona y otras dicen que no.

Gracias por sumergirte más allá, @ rally25rs.

1. Re: uso de force en el comando eliminar.
   Esa fue claramente una corrección de error de esquina de corte rápido que logró la corrección con un enfoque nuclear IIRC https://github.com/yarnpkg/yarn/pull/323.
   No debería ser difícil eliminar force y solucionar el problema.

2. node_modules/uws/uws_darwin_57.node : este archivo debe estar en el campo artifacts de .yarn-integrity y luego uws no debe marcarse como no actualizado durante el enlace.
   Probablemente algo anda mal aquí

@bestander ah buen punto en 2. Trataré de ver si hay una manera sensata de trabajar eso en la cuenta.

@stereokai En mi comentario anterior, noto que npm también reconstruye paquetes al desinstalar / eliminar, por lo que ese caso es posiblemente "correcto" si considera que el comportamiento de npm es el estándar.

@ rally25rs Gracias por señalar eso :)

Sin embargo, considero que este comportamiento tiene errores independientemente del administrador de paquetes. Es difícil entender por qué este tipo de comportamiento es incluso necesario para un funcionamiento correcto. Su sistema operativo no reinstala programas locales cuando agrega / elimina otro, porque las aplicaciones ya están allí. No esperaría nada más de un administrador de dependencias estáticas, ¿nahmean?

@stereokai Estoy algo de acuerdo, por eso usé la frase "posiblemente correcto" 😆
Su sistema operativo tampoco cambia donde se instalan otras aplicaciones cuando desinstala una no relacionada.

Suponga que tiene un árbol de dependencia como:

myProj
  |- depA v1
  |    |-depB v2
  |- depB v1

Si instala esto, entonces formaría la misma estructura de directorio bajo node_modules , porque no puede llevar depB a la raíz.

myProj
  |- node_modules
       |- depA v1
       |   |- node_modules
       |        |-depB v2
       |- depB v1

Pero de ti yarn remove depB entonces la nueva estructura de depósito es:

myProj
  |- depA v1
       |-depB v2

myProj
  |- node_modules
       |- depA v1
       |- depB v2

por lo que el directorio real donde se instala depB v2 puede cambiar cada vez que se agrega o elimina un paquete. Esos directorios no solo se copian de una ubicación a otra. El anterior se elimina y el nuevo se copia del caché al nuevo destino, lo que significa que los artefactos de compilación que estaban en node_modules/depA/node_modules/depB ya no existirían y necesitarían reconstruirse en node_modules/depB .

Del mismo modo, yarn add [email protected] cambiaría la ruta donde se instala depB v2 (de hecho, debería probar que mi RP no se reconstruya en yarn add realidad funciona en este caso)

Sospecho que es por eso que estos paquetes se reconstruyen cada vez.

El cambio real ocurrió en esta confirmación: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
en 2016. El archivo se llamaba uninstall.js en ese momento, pero force: true se agregó a las banderas pasadas a install . No parece haber nada específico en el comentario de confirmación para indicar _por qué_.

Sería increíble si hubiera una manera de evitar las reconstrucciones en al menos _algunos_ casos.

Cualquiera es bienvenido a trabajar en un PR. 😸Como señalé anteriormente, las reconstrucciones ya no ocurren en yarn install y yarn add (en la mayoría de los casos). Tengo el # 5470 abierto que debería eliminar las reconstrucciones innecesarias para yarn add cuando tiene uws en sus dependencias (u otros paquetes que cambian sus propios archivos durante la instalación). El único caso restante que conozco es yarn remove .

Después de haber leído la mayor parte de este hilo, no entiendo lo que está sucediendo aquí.

Tengo varios paquetes nativos que se están reconstruyendo cada vez que uso yarn add para cualquier otro módulo (no relacionado). Se necesitan alrededor de 20 minutos de una carga muy alta en las CPU de mi computadora portátil. Simplemente no puedo trabajar de esa manera.

Al parecer, desde este hilo, ha sido un problema durante 19 meses.

¿Es un error? ¿Se está trabajando en ello? ¿Existe alguna solución? ¿Debería volver a cambiar a npm?

¿Debería volver a cambiar a npm?

sí, hasta que se publique el número 5470.

@vibl

Al parecer, desde este hilo, ha sido un problema durante 19 meses.

En realidad, se solucionó (en su mayoría) hace mucho tiempo. Este hilo permanece abierto para un caso de borde que encontré hace unas semanas donde yarn reconstruirá un paquete si ese paquete cambió alguno de sus archivos (cree que el archivo es incorrecto en comparación con lo que estaba en la descarga original, por lo que quiere arreglar eso). Y para una discusión abierta sobre si remove y upgrade deberían hacer una reconstrucción (lo hace en npm, pero tal vez no debería)

¿Es un error?

Tal vez. ¿Qué paquetes se están reconstruyendo? El único que conozco que ha sido un problema constante es uws , por lo que sería útil saber más.

¿Se está trabajando en ello?

El caso específico que mencioné anteriormente está arreglado en el # 5470

¿Existe alguna solución?

Si el paquete que está agregando no tiene ningún script de instalación, entonces puede usar --ignore-scripts

O bien, puede consultar la rama del PR anterior y usarla.

Tarda unos 20 minutos

Guau. Tengo curiosidad por saber qué paquete es ese.

Gracias por responder.

Los paquetes noise-search , level-rocksdb y jq recompilan cada vez que agrego cualquier paquete no relacionado con yarn add . Mi computadora portátil es un poco vieja, por lo que lleva mucho tiempo compilarlos al mismo tiempo.

Usé Yarn 1.5.1 y el nodo 9.8.0.

@vibl yeesh, noise-search es definitivamente el culpable de las compilaciones largas ...

~/Projects/yarn-test 🐒   yarn add noise-search
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 73 new dependencies.
✨  Done in 426.15s.

más de 7 min en una MacbookPro 😢

De todos modos, instalé noise-search luego ejecuté un yarn add left-pad con el código de # 5470 y _no_ causó una reconstrucción, así que creo que debería estar listo una vez que lo fusionemos 👍

Gracias :-)

¿Debería volver a comprobar Yarn en unos días, unas semanas o unos meses?

Acabo de descubrir que este error, con el mismo proyecto exacto en la misma computadora portátil (arranque dual), no ocurre en Windows 10. Pero está ahí en las últimas tres versiones de Debian, Ubuntu, Arch Linux y Fedora. Extraño. Todavía no probé MacOS, pero parece que algunas personas también tienen problemas allí.

@vibl No estoy seguro de cuándo será nuestro próximo lanzamiento (no estoy involucrado en esa planificación)

@nnmrts sí, descubrí que es algo específico del sistema operativo. De mis comentarios en el n. ° 5470:

en Linux con el nodo 8, cuando los archivos se copian de la caché a node_modules, las marcas de tiempo se actualizan. yarn decide que los archivos son diferentes y marca la referencia como fresca.
Sin embargo, esto solo parece suceder en el nodo 8 de Linux.
esto se debe a que Node v8.5 introdujo fs.copyFile que hizo copias mucho más rápido. IIRC que llega a la copia del sistema de archivos nativo, por lo que eso explicaría por qué funciona de manera diferente en los sistemas operativos y solo en el nodo 8.

@ rally25rs @nnmrts Definitivamente no es algo específico de MacOS. También ocurre en mi PC con Win10

@stereokai Bueno, todo este tema no es específico. A veces, los paquetes necesitan ser reconstruidos y la gente todavía piensa que es un error y lo publica aquí. Sin un repositorio sólido y reproducible para cada sistema operativo, no podemos saber nada.

¿Puede ayudar el almacenamiento en caché local de módulos construidos (de # 5314) ?:

Agregue .yarnrc a su proyecto con lo siguiente:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

Después de la primera instalación, los módulos precompilados vivirán en ./<your-offline-mirror-path>/prebuilt . yarn.lock también se actualiza con variantes precompiladas

Extrajo el último 66a0143a753cd4ade1a0fffee2174890d564c129, y parece que funciona correctamente😎

TODAVÍA descarga binario repetidamente.

• nodo v6.13.1
• hilo v1.6.0-20180327.1507
• SO: Ubuntu 17.10 Linux 4.13.7-041307-genérico
• ~ / .yarnrc:

yarn-offline-mirror "./<your-offline-mirror-path>"
experimental-pack-script-packages-in-mirror true

yarn add node-sass
yarn remove node-sass
yarn add node-sass

El jueves, 29 de marzo de 2018 a las 2:30 a. M., Andrew Lane [email protected]
escribió:

Almacenamiento en caché local de módulos construidos (de # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) puede ayudar ?:

Agregue .yarnrc a su proyecto con lo siguiente:

hilo-offline-espejo "./"
experimental-pack-script-packages-in-mirror true

Después de la primera instalación, los módulos precompilados vivirán en
.// prediseñado. yarn.lock también se actualiza
con variantes prediseñadas

Sacó el último 66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
y parece estar funcionando correctamente😎

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

@snowyu , ¿borraste yarn.lock, node_modules y yarn cache clean ? ¿./Yarn-offline-mirror/prebuilt se completa después de la instalación?

Es un nuevo proyecto en temp. Sí, puedo ver el archivo node-sass-4.8.3.tgz en la carpeta de caché.
Ahora, ejecuto yarn cache clean . PERO TODAVÍA descarga binario repetidamente * .

`` bash

yarn init -y
hilo añadir nodo-sass
hilo añadir v1.6.0-20180327.1507
info No se encontró ningún archivo de bloqueo.
[1/4] Resolviendo paquetes ...
[2/4] Obteniendo paquetes ...
[3/4] Vinculando dependencias ...
[4/4] Construyendo paquetes nuevos ... Descargando binario desde https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
éxito Archivo de bloqueo guardado.
éxito Salvó 152 nuevas dependencias.
Hecho en 11,98 s.

hilo añadir nodo-sass
hilo añadir v1.6.0-20180327.1507
[1/4] Resolviendo paquetes ...
[2/4] Obteniendo paquetes ...
[3/4] Vinculando dependencias ...
[4/4] Construyendo paquetes nuevos ... Descargando binario desde https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
éxito Archivo de bloqueo guardado.
éxito Guardado 1 dependencia nueva.
info Dependencias directas
└─ [email protected]
info Todas las dependencias
└─ [email protected]
Hecho en 13.45s.
''

OK, hice un simple repositorio de git para reproducir este error.

https://github.com/vlmonk/yarn-bug-test

el hilo realiza una reconstrucción innecesaria ttf2woff2 cuando trato de agregar dependencia cero left-pad

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
yarn
[ ... building binary package here ... ]
yarn add left-pad
[ ... rebuilding binary packages here ... ]

Puedo reproducir esto tanto en el sistema host OSX como en el contenedor de la ventana acoplable con la última imagen node

NPM funciona correctamente en este caso:

git clone https://github.com/vlmonk/yarn-bug-test
cd yarn-bug-test
npm i 
[ ... building binary package here ... ]
npm i left-pad
[ ... don't rebuild binary packages here ... ]

Mi versión de hilo 1.5.1

@vlmonk, ¿esto todavía sucede si clona https://github.com/rally25rs/yarn de @ rally25rs y usa el código en # 5470 (rama fix-linking-rebuilding-uws-932 )?

@karlhorky sí, el hilo aún se reconstruye ttf2woff2 después de agregar left-pad

# which yarn
yarn: aliased to node /Users/monk/work/yarn/lib/cli/index.js
# yarn --version
1.6.0-0

El paquete ttf2woff2 viene con archivos que se modifican en el paso de compilación. En la siguiente ejecución, yarn ve esos archivos cambiados y reinstala el paquete.

Yarn debería manejar mejor esta situación: debería ver que esos archivos cambiaron durante el paso de compilación y debería aceptar esos archivos modificados como los archivos "correctos", no tratarlos como una razón para una reinstalación.

Verifiqué esto con un registro adicional (https://github.com/sth/yarn/tree/trace-rebuild). En la primera instalación, muestra:

build artifacts for ttf2woff2
  modified file: build
  modified file: build/Makefile
  modified file: build/Release
  modified file: build/Release/.deps
  modified file: build/Release/.deps/Release
  modified file: build/Release/.deps/Release/addon.node.d
  modified file: build/Release/.deps/Release/obj.target
  modified file: build/Release/.deps/Release/obj.target/addon
  modified file: build/Release/.deps/Release/obj.target/addon/csrc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/addon.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/backward_references.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/block_splitter.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/encode_parallel.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/entropy_encode.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/histogram.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/literal_cost.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/metablock.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/enc/streams.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/font.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/glyph.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/normalize.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/table_tags.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/transform.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/variable_length.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_common.o.d
  modified file: build/Release/.deps/Release/obj.target/addon/csrc/woff2/woff2_enc.o.d
  modified file: build/Release/.deps/Release/obj.target/addon.node.d
  modified file: build/Release/addon.node
  modified file: build/Release/obj.target
  modified file: build/Release/obj.target/addon
  modified file: build/Release/obj.target/addon/csrc
  modified file: build/Release/obj.target/addon/csrc/addon.o
  modified file: build/Release/obj.target/addon/csrc/enc
  modified file: build/Release/obj.target/addon/csrc/enc/backward_references.o
  modified file: build/Release/obj.target/addon/csrc/enc/block_splitter.o
  modified file: build/Release/obj.target/addon/csrc/enc/brotli_bit_stream.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/encode_parallel.o
  modified file: build/Release/obj.target/addon/csrc/enc/entropy_encode.o
  modified file: build/Release/obj.target/addon/csrc/enc/histogram.o
  modified file: build/Release/obj.target/addon/csrc/enc/literal_cost.o
  modified file: build/Release/obj.target/addon/csrc/enc/metablock.o
  modified file: build/Release/obj.target/addon/csrc/enc/streams.o
  modified file: build/Release/obj.target/addon/csrc/woff2
  modified file: build/Release/obj.target/addon/csrc/woff2/font.o
  modified file: build/Release/obj.target/addon/csrc/woff2/glyph.o
  modified file: build/Release/obj.target/addon/csrc/woff2/normalize.o
  modified file: build/Release/obj.target/addon/csrc/woff2/table_tags.o
  modified file: build/Release/obj.target/addon/csrc/woff2/transform.o
  modified file: build/Release/obj.target/addon/csrc/woff2/variable_length.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_common.o
  modified file: build/Release/obj.target/addon/csrc/woff2/woff2_enc.o
  modified file: build/Release/obj.target/addon.node

El archivo del paquete https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz de hecho contiene esos archivos.

También vemos esto con OS X, agregar cualquier paquete con yarn add activa una recompilación de cualquier paquete dependiente. Tenemos un paquete node-gyp con código nativo, toma más de 1 minuto cada vez que se agrega otro paquete, y todavía no hay mucho código en el módulo nativo (empeorará mucho). Esto es con hilo 1.5.1.

Estamos usando yarn add ../a con rutas relativas si eso hace una diferencia.

Avíseme si hay alguna solución alternativa o cuándo se solucionará.

Esto es con hilo 1.5.1.

Este problema se solucionó en 1.6.0, que salió bastante recientemente.

Todavía veo esto con 1.6. Desde que pasó de npm a yarn hace mucho tiempo uws como siempre reconstruido (o al menos yarn ha quedado atascado en uws por aproximadamente 5-10 segundos).

Pasos para reproducir:

1. $ hilo desactualizado
2. elige un paquete desactualizado
3. $ actualización de hilo [paquete]

@grantila, ¿puedes proporcionar un package.json completo o un repositorio con pasos que reproduzcan esto con Yarn 1.6.0 ?

esto todavía está sucediendo en 1.6.0

puede reproducir esto usando este https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784

Tengo un proyecto simple y también estoy viendo esto. Agregar o eliminar un paquete parece desencadenar una reconstrucción completa de al menos un paquete cada vez.

"dependencies": {
    "bufferutil": "3.0.4",
    "chance": "1.0.16",
    "discord.js": "11.3.2",
    "dog-facts": "1.0.3",
    "erlpack": "discordapp/erlpack",
    "flickr-sdk": "3.7.0",
    "html-entities": "1.2.1",
    "node-opus": "0.2.7",
    "snekfetch": "4.0.0",
    "sodium": "2.0.3",
    "utf-8-validate": "4.0.1"
  }

Después de instalarlos, agregué el paquete unescape , que provocó una reconstrucción de sodium . Luego lo eliminé, lo que provocó una reconstrucción de lo que parecía ser cada paquete que necesitaba ser compilado. ¡Agregar este paquete simple tomó 36 segundos y quitarlo 100!

EDITAR: usando Node 8.11.1 y yarn 1.6.0 en Debian Stretch.

@arcanis @ rally25rs, por favor, vuelva a abrir el problema, varios informes de que esto sigue sucediendo, incluso con la solución combinada.

Creo que esto es más un problema de @ rally25rs :)

@grantila an upgrade _siempre_ reconstruirá todo. Esto es intencional. npm hace lo mismo (menciono esto en un comentario en algún lugar de este largo hilo) aunque podríamos intentar dejar de hacer eso. No estoy seguro de las repercusiones que pueda tener.

Todos los demás:

En el n. ° 5680 señalo que esto todavía sucede si un paquete elimina sus propios archivos _ (¿por qué, oh, por qué hacen estas cosas?) _ Y Yarn no rastrea eso en ninguna parte (rastreamos qué archivos se crean o modifican), así que simplemente piensa que al paquete le faltan archivos y lo reconstruye.

Supongo que podemos volver a abrir esto, pero se ha solucionado para la mayoría de los paquetes. Si alguien quiere agregar "yo también" a esto, _por favor_ proporcione su package.json, o mencione específicamente qué paquete se está reconstruyendo continuamente, ya que puede tener algunas dependencias que se reconstruyen y otras que no.

¡Cualquiera es bienvenido para hacer un PR por esto! (vea mis comentarios de depuración en # 5680)

Perdón por agregar más ruido, pero me gustaría sugerir bloquear este problema y señalar uno nuevo con esta información más reciente en la parte superior.

Creo que el problema aquí ha cambiado bastante y se ha resuelto al menos parcialmente. Con todas las publicaciones aquí, es difícil para alguien nuevo ponerse al día con lo que se ha solucionado y lo que sigue siendo un problema.

Estoy de acuerdo con @ james-rabbit

Sí, tienes razón. Voy a bloquear este para que la respuesta de @ rally25rs permanezca visible.

Si tiene algún problema con los paquetes nativos:

• Si sucede con todas las dependencias nativas, abra un problema genérico. Este problema debería haberse resuelto, por lo que no espero ver uno pronto; aún así, si puede proporcionar los pasos de reproducción, no dude en abrir un nuevo problema (y puede vincularlo a este si lo desea).

• Si sucede con una dependencia nativa