Yarn: Pacotes nativos reconstruídos sempre

Não é possível reproduzir isso no Mac OSX (10.11.6), então pode ser um problema específico do Ubuntu?

Eu poderia reproduzir no Windows 10, mas apenas uma vez. A segunda vez que executei "yarn", ele não reconstruiu as bibliotecas nativas. Estranho.

Eu estava brincando um pouco mais e descobri mais alguns detalhes:

1. Se eu executar yarn add leveldown bcrypt , leveldown será compilado como o primeiro item da lista e o hash em node_modules/.yarn-integrity será igual a 595306... quando terminar (cortar para ser breve; suponho que seja uma soma de verificação que determina se algo precisa ser feito). Agora, se eu executar apenas yarn novamente, ambos os pacotes serão reconstruídos com bcrypt sendo compilado como o primeiro na lista (a ordem é diferente). A soma de verificação resultante será igual a cbe480... . A invocação subsequente de yarn não reconstruirá os pacotes e a soma de verificação permanecerá a mesma. Isso contradiz meu relatório original (provavelmente cometi um erro em algum lugar), mas está de acordo com o que @ Daniel15 estava vendo.
2. Quando eu inverto a ordem dos pacotes desde o início ( yarn add bcrypt leveldown ), bcrypt será o primeiro na lista e a soma de verificação resultante será igual a cbe480... imediatamente. A invocação subsequente de yarn não reconstruirá os pacotes.
3. O pacote bcrypt sempre terminará primeiro (como esperado, já que simplesmente não há muito para compilar), independentemente da posição na lista.

Não estou familiarizado com os detalhes internos, mas parece-me que a ordem em que os pacotes são compilados é importante e eles simplesmente não estão sendo classificados quando instalados pela primeira vez (e eles _são_ classificados quando mais tarde invocar yarn ) que afeta a soma de verificação de alguma forma.

Obrigado por investigar! Parece uma boa pista. O hash está escrito aqui: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Pode valer a pena depurar esse código e ver o que há de diferente no arquivo de bloqueio, pois o hash em .yarn-integrity é baseado no arquivo de bloqueio.

Pode valer a pena depurar esse código e ver o que é diferente no arquivo de bloqueio, já que o hash em .yarn-integridade é baseado no arquivo de bloqueio.

Suspeitei disso, mas o que me desconcertou foi o fato de o arquivo de bloqueio não mudar, é sempre o mesmo. É apenas o hash na integridade do .yarn que muda.

$ 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

Tenho o mesmo problema: também uso o bcrypt. Sempre que instalo alguns módulos novos ou atualizo os existentes, tenho que executar npm rebuild para tornar meu aplicativo executável.

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

Não consigo mais reproduzir o problema original. Parece ter sido corrigido: +1 :. @ Daniel15 Pode confirmar?

@hustcer Não acho que seja o mesmo problema. Você pode querer testar a versão mais recente e registrar um novo bug se ainda não estiver funcionando para você.

@jiripospisil Obrigado, está tudo bem agora após a atualização para o yarn v0.17.4.

Ainda estou vendo isso, ou algo muito semelhante, no 0.18.1. A propósito, também é a redução de nível que é reconstruída repetidamente. Usando o teclado esquerdo como um pacote sem dependências (e que não depende do nível inferior) para fins demonstrativos, as etapas de reprodução são as seguintes:

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

Segue minha saída quando eu executo isso. Observe que a remoção do painel esquerdo leva quase 40 segundos, a maioria dos quais reconstruindo a redução do nível. Isso acontece de forma consistente, com e sem nivelamento ou teclado esquerdo no cache do Yarn, embora apenas durante remove e 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.

Versões:

Node v7.3.0
Fio 0.18.1
OS X El Capitan (10.11.6)

Por favor, reabra enquanto isso ainda acontece.
Simplesmente fiz yarn add redux e reconstruiu bcrypt , node-sass e vários outros.

Node v6.9.4
Yarn v0.20.3
Windows 10

@seansfkelley Eu segui seus passos com a última versão e funcionou. Você poderia tentar novamente?

/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 Você poderia adicionar algumas etapas de reprodução? Tentei algumas combinações, mas funcionou.

Nó 7.3.0
Fios 0,20.3
MacOS 10.12.3

@jiripospisil Não tenho etapas de reprodução para fornecer, simplesmente instalar um pacote adicional faz com que o yarn vincule e reconstrua tudo.

Aqui está o resultado da adição de um pacote (o arquivo de bloqueio já existe):

Dependências de vinculação:

Reconstruindo:

@jiripospisil Eu também ainda estou vendo isso, mas durante a minha reprodução eu tropecei porque parece que o nivelamento (ou uma dependência disso) pode ter começado a enviar um binário compatível com o OS X, então o tempo de instalação caiu suspeitamente de 50 para 3 segundos. Se você estiver no OS X e especificamente yarn add [email protected] vez de apenas yarn add leveldown , deverá ver o mesmo comportamento de antes.

Tenho uma dependência indireta de ttf2woff2 , que também reconstrói todas as vezes.

No entanto, ele só é reconstruído sempre que houver uma alteração em yarn.lock . Ou seja, yarn com um novo yarn.lock , yarn upgrade , yarn upgrade-interactive . No caso de yarn upgrade-interactive , se ambos os devdeps e os departamentos regulares forem atualizados, ttf2woff2 será reconstruído duas vezes (!).

Também estou vendo esse problema, embora não tenha conseguido reproduzi-lo com as etapas acima. No entanto, posso reproduzi-lo com estas etapas:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

fio adicionar co
`` `

então, novamente, ele cria um nível inferior.

Não parece importar o pacote que eu adiciono, ele sempre reconstrói o nível inferior.

Estou usando o Yarn v0.21.3, Windows 10 e Node v7.7.1

Estou vendo isso também. Estou usando BuckleScript (bs-platform) ....

Também estou encontrando esse problema com sharp . Cada vez que executo yarn add ou yarn remove , sharp seria reconstruído, mesmo com pacotes não nativos.

Testado no yarn v0.21.3, Node 7.0.0, no Windows 10 e Ubuntu Linux 16.04.

Aqui estão as dependências de package.json , se isso ajudar:

{
  "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"
  }
}

também vendo isso com bs-platform

Também experimentar isso com ttf2woff2 cada chamada para yarn add reconstrói ttf2woff2 , embora não tenha sido publicado em mais de um ano.

Eu tenho isso com o couchbase também

editar: parece estar corrigido em 0.23.2

Isso ainda acontece comigo na versão 0.23.2 ( argon2 e node-sass são reconstruídos toda vez que adiciono / removo algum pacote não relacionado como moment que não tem dependências)

SO: Windows 10
Nó: 7.9.0
Fio: 0.23.2

Para adicionar um pouco mais de cor, minha percepção de que isso estava acontecendo em yarn add <some-package> foi muito maior do que a realidade, pois muitos casos para mim foram realmente acionados pela combinação com yarn remove <unrelated-package> imediatamente antes, devido ao force: true nesta linha .

Certamente conveniente reutilizar a lógica de instalação em remove para gerar o lockfile, mas seria bom se ele não viesse com toda a bagagem de uma instalação forçada :)

Para mim, isso começou a acontecer novamente quando atualizei para 0.23.x. Eu reverti para 0.21.3 e ele não cria mais todas as vezes. Isso também levou a este problema em que meu IP foi bloqueado por unicode.org após atualizar alguns pacotes em uma linha https://github.com/dodo/node-unicodetable/issues/16

Enquanto 0.21.3 não reconstrói todos os pacotes ao adicionar um novo pacote, ele reconstrói todos os pacotes ao remover. E parece que o fio não considera um fracasso se a reconstrução falhar.

Para mim, diminuir para 0.21.3 não ajudou. bs-platform é reconstruído a cada adição / remoção.

Vendo isso no macOS com o Yarn 0.23.4. Reconstrói sqlite3 sempre que executo 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.

Ver este problema com Ubuntu 16.04LTS, com o yarn v0.24.6 mais recente, com nó 8.1.2

Estou vendo gdal , node-sass reconstruindo toda vez que adiciono um módulo, isso está fazendo com que a adição de fios demore mais para ser executada do que o necessário.

Estou vendo isso também, é super irritante em um Raspberry Pi Zero W, onde a construção de pacotes (como o bleno) pode levar vários minutos.

Ainda estou vendo isso com Yarn v0.27.5 e uws . Cada vez que algo muda em meus pacotes, o uws é reconstruído.

A única coisa interessante que posso ver sobre uws é que ele não tem um campo de dependências em package.json .

Isso está se tornando uma grande frustração para mim nos últimos dias. Eu tinha windows-build-tools instalado globalmente em um estágio (realmente só precisa se construir uma vez para configurar o ambiente de desenvolvimento do Windows para pacotes nativos) que ficava se reconstruindo sempre que adicionava um pacote. Como você pode imaginar, demorou um pouco e acabei percebendo que não precisava mais dele instalado e removi-o.

Agora parece que node-sass continua querendo reconstruir em outro projeto ao adicionar pacotes.

Esse comportamento ocorre tanto em yarn add quanto em yarn remove para mim. Certamente, nenhuma reconstrução é necessária para essas etapas, pois os pacotes nativos são construídos apenas uma vez de acordo com a versão do Node.

Editar: usando Node v8.2.1 e Yarn v0.27.5 no Windows 10.

Não consigo contar quantas vezes uws foi reconstruído para mim :) Observe que uws
tem zero dependências e até mesmo falta o campo em package.json

Na segunda-feira, 31 de julho de 2017, às 22h50 Paul Myburgh [email protected]
escrevi:

Isso está se tornando uma grande frustração para mim nos últimos dias. eu tinha
windows-build-tools instalados globalmente em um estágio (só precisa realmente
construir-se uma vez para configurar o ambiente de desenvolvimento do Windows para
pacotes) que se reconstruíam sempre que eu adicionava um pacote. Como
você pode imaginar que demorou um pouco e acabei percebendo que não
precisa mais dele instalado e removido.

Agora parece que o node-sass continua querendo reconstruir em outro projeto
ao adicionar pacotes.

Esse comportamento ocorre tanto na adição de fios quanto na remoção de fios para mim. Com certeza não
a reconstrução é necessária para essas etapas, pois os pacotes nativos são apenas construídos
uma vez de acordo com a versão do Node?

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

Estou no 0.27.5 e continuo vendo esse comportamento com bs-platform .

É uma grande frustração, idem aqui com bs-platform .

Belo senso de direito lá ... Que tal um Tim PR?

Em Ter, 22 de agosto de 2017, 10:44 Tim Shnaider [email protected]
escrevi:

FFS pode ser consertado, por favor.
Forneça pelo menos uma opção de linha de comando ou configuração env para desativá-lo.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

Parece não ter sido mencionado até agora, mas também posso reproduzir esse bug com yarn global list .

Passos para reproduzir:

1. Use um novo env:: aviso: execute-o apenas se souber o que está fazendo

   rm -rf ~/.config/yarn/
   

2. Adicione um pacote 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. Execute yarn global list e veja alguns pacotes nativos sendo recompilados

4. Repita o quanto quiser, yarn global list sempre recompilará os pacotes nativos
5. 😭

Eu espero que isso ajude.

ℹ️ MacOS 10.12.6 com Yarn 0.27.5 instalado via Homebrew.

O direito é desnecessário, mas posso entender a frustração. Isso está desperdiçando muito tempo de muitas pessoas (reinstalações longas se acumulam com o tempo e interrompem o fluxo). Claro, você pode dizer "faça uma solicitação de pull" - e isso é justo. Mas seria um processo de aprendizagem em cima de alterar potencialmente apenas algumas linhas de código ... O que esperamos é que as pessoas que conhecem os meandros deste projeto priorizem este problema no próximo lançamento, pois realmente parece bastante importante (e potencialmente uma solução fácil? Evite reinstalar binários se a versão do Node não mudou, talvez).

Já faz quase um ano desde que foi relatado pela primeira vez.

Espero não ter o direito de dizer isso ... Gostaria de acrescentar que estou muito grato por este projeto e pela utilidade que ele já me traz. Esse problema foi um dos poucos pontos problemáticos que tive.

EDIT: Acabei de fazer um yarn remove para um pacote aleatório e ele tentou e (desta vez) falhou ao reconstruir meus binários. O efeito colateral é que meus binários estão completamente ausentes agora e parece que a única maneira de consertar é com um npm rebuild . Portanto, não apenas parece que esse problema causa reconstruções desnecessárias - mas, se o processo falhar, parece que você terá que recorrer a npm para consertá-lo novamente.

Estou vendo o mesmo comportamento de @zhangjyr e @lostpebble. Executar yarn add funciona bem, mas yarn remove faz com que os pacotes nativos sejam reconstruídos.

Mac Sierra 10.12.6
Fio 0,27,5

Vou tentar ver o que posso fazer sobre isso, já que isso também me afeta. Dito isso, não é tão difícil contribuir com o Yarn, então, se alguém quiser enviar um PR, experimente e tentaremos apoiá-lo tanto quanto possível.

Não poderei trabalhar nisso por algumas semanas.

Eu também estou vendo isso.
Trabalhando no local baseado em gatsby. QUALQUER operação de fio causa reconstrução.
Experimente criar um site com gatsby e falar com ele. Espero que isto ajude

Vendo isso em um projeto usando gatsby:
fio 1.0.2
nó 7.10.1
ubuntu 16.04

Este problema está se tornando muito sério agora. Não são apenas meus binários sempre reconstruídos. Mas é comum que meus binários sejam completamente removidos após yarn add ou yarn install (após alterar os números de versão de um pacote em package.json para atualizar / reverter um módulo). E não importa o quanto eu execute yarn install ou yarn install --check-files depois, esses binários simplesmente se perdem e se vão e nunca mais voltam. A única maneira de recuperá-los é com npm rebuild .

Está começando a parecer que o yarn não tem nenhum conhecimento sobre o estado das embalagens nativas. Se já estão instalados / construídos ou se não foram instalados / construídos corretamente.

Talvez tenha havido algum progresso nisso?

Acho que a recente adição do campo artifacts ao arquivo de integridade do fio por @arcanis ajudaria a corrigir esse problema. Nenhum progresso ainda, mas aberto a PRs :)

Eu tenho um problema semelhante com a bs-platform ao instalar pacotes em meu projeto reasonml

O mesmo ... literalmente cada yarn add reconstruirá o projeto gyp.

Acontece aqui também.
(fio 1.2.1)

Eu vejo isso com node-sass .

Acontece comigo com o Cypress, por exemplo.

node -v
v8.8.1
fio -v
1.2.1

✋ Em vez de escrever "Eu também" sem informações adicionais, use o recurso +1 no Github na postagem superior . Cada vez que você escreve um comentário "eu também", 35 assinantes são notificados desnecessariamente.

+1

Apenas clique em Subscribe se quiser receber atualizações. Espero que todos queiram ser notificados quando for resolvido, mas não quando alguém novo enfrentar esse problema também.

@BYK você pode bloquear o tópico e torná-lo disponível apenas para proprietários.

No momento, estou investigando esse problema e tentando reduzi-lo a um caso de teste reproduzível mínimo. Um "ótimo" pacote para demonstrar esse problema é htmlstrip-native - leva alguns minutos para compilar, então você não pode perdê-lo.

Adoraria que alguém tentasse este package.json em uma pasta vazia:

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

Tente executar estes comandos:

yarn
yarn upgrade [email protected]

Na minha máquina, com o yarn mais recente 1.2.1, o comando upgrade resulta em uma reconstrução de htmlstrip-native que leva uma eternidade. O Yarn não deveria reconstruí-lo, já que atualizar left-pad não tem efeito em htmlstrip-native ou em suas dependências.

Agora tente npm :

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

Na minha máquina, o segundo comando (corretamente) não resulta em uma nova reconstrução de htmlstrip-native .

EDITAR : Ao reler todas as postagens acima, parece que este caso não será surpresa para ninguém - a maioria das pessoas, inclusive eu, estão descobrindo que simplesmente pedir ao fio para fazer _qualquer_coisa_ resulta em uma reconstrução. Acho que este não é um problema maior na comunidade porque a maioria das pessoas não usa pacotes nativos que levam muito tempo para construir - então eles não têm uma etapa de reconstrução ou termina tão rápido que quem se importa.

OK, depois de muita depuração, parece que esse comportamento é intencional. Rastreando pelo código, parece que, por exemplo, yarn upgrade [email protected] resultam nas seguintes etapas:

1) upgrade módulo é chamado, que executa uma operação new Add() para left-pad .
2) Add.init() chama sua superclasse, Install.init()
3) Install.init() enfileira uma etapa de rebuildingPackages
4) Em PackageInstallScripts.init() ele simplesmente coleta _todos_ os pacotes e os adiciona aos workQueue para serem reconstruídos.
5) PackageInstallScripts então descobre que há um comando de instalação para htmlstrip-native e apenas o executa - esta é a reconstrução nativa superlenta que todos nós estamos vendo.

De tudo o que vi até agora, parece não haver lógica que pretenda filtrar os pacotes que não "precisam" ser reconstruídos. É simplesmente reconstruir tudo, conforme declarado na saída do console.

Adoraria que alguém da equipe do Yarn falasse aqui - se esse comportamento for realmente intencional, recomendo encerrar esta edição!

Para minha situação pessoal, vou apenas trocar minha dependência de htmlstrip-native pois não há razão para que ela leve alguns minutos para construir (é como, alguns pequenos .c arquivos). O resto dos meus dep. Nativos são construídos rapidamente, então não é um grande problema se isso acontece o tempo todo.

Parece um efeito colateral não intencional do design, mas talvez alguém em @ yarnpkg / core possa comentar sobre isso. Não acho que seja para reconstruir pacotes que não precisam ser reconstruídos.

Isso não é intencional; provavelmente, é apenas mais fácil de implementar dessa forma.
Há um comentário acima da BYK que diz que esse problema está procurando um PR:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Certamente os pacotes nativos pesados ​​não são comuns o suficiente para aparecer como prioridade mais alta para o Yarn, no entanto, o Yarn tem a capacidade de não reconstruir pacotes em cada instalação.
Este parece ser um bug que deve ser corrigido diretamente, envie um PR.
Pode haver advertências porque o Yarn não pode saber com certeza se um pacote compilado pode ter sido corrompido, é por isso que ele está reexecutando ansiosamente os scripts de instalação agora.

Existe um fork do Yarn que é usado pela equipe por trás do Reason https://github.com/esy-ocaml/esy-install que contorna muitos problemas de compilação nativa porque as dependências do Reason / Ocaml requerem uma compilação pesada.
Conforme essa abordagem amadurece, espero que seja possível mesclar as alterações no upstream.

Portanto, fundamentalmente, os pacotes nativos são reconstruídos porque:

1) A bandeira force=true foi definida, ou
2) O pacote foi marcado fresh=true .

Parece que com alguns comandos (como upgrade e remove ), o sinalizador force é definido como verdadeiro "apenas no caso". Este sinalizador promete "reconstruir todos os pacotes independentemente de terem sido alterados", portanto, não faz sentido adicionar algum código de detecção de alterações porque isso quebraria essa promessa.

Então, para corrigir isso, parece que precisaremos desafiar as suposições dos vários lugares no código que definem force=true .

O primeiro que rastreei acontece ao executar yarn upgrade whatever . Ele foi introduzido neste commit como parte de # 2780 por @juanca. As notas de confirmação dizem:

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

Talvez @juanca ou alguém mais familiarizado com a história do yarn possa intervir com o problema que isso pretendia resolver?

@nfarina obrigado, isso traz clareza. Para atualizações, talvez realmente queiramos forçar a construção de pacotes nativos (se eles estiverem sendo atualizados). Mas para instalações (yarn add), eu diria que precisamos desafiar legitimamente, como você disse, a suposição de que os pacotes nativos já instalados são reconstruídos quando algo mais é instalado.

Suponho que o sinalizador force esteja definido de forma que o resolvedor de Yarn não ignore a dependência existente porque a versão antiga está em yarn.lock.

Acho que foi uma solução rápida para fazer a atualização funcionar.
Uma maneira adequada seria passar outro sinalizador que afeta apenas a resolução de pacotes especificados e não será tão nuclear quanto force .
Envie um PR :)

Talvez @juanca ou alguém mais familiarizado com a história do yarn possa intervir com o problema que isso pretendia resolver?

Correto, eu estava trabalhando apenas com a API Add - ela não faz (fez?) Nada ao adicionar um pacote existente.

Eu também recomendo usar uma técnica melhor para controlar o fluxo do procedimento.

Estou usando yarn on my raspberry pi zero em um projeto que depende do node-opencv. Cada vez que adiciono / removo / atualizo um pacote não relacionado, tenho que esperar 35 minutos para a reconstrução.

@ Torsten85 , também o uso no pi, sim, reconstruções desnecessárias é algo que precisamos resolver.
Você pode fornecer um script de reprodução para suas reconstruções?

o mesmo aqui, no lubuntu 17.10, quando uso yarn, desenvolvendo com https://github.com/mui-org/material-ui

cada yarn add/remove (-D) <pkg> reconstruir tudo, como uma nova instalação, leva mais de 1 minuto

É assim que o npm lida com isso também? Caso contrário, seria uma solução alternativa para alternar temporariamente?

está acontecendo também aqui

• nó 9.2.0
• fio 1.4.0

cada vez que adiciono alguma dependência, módulos como bcrypt ou couchbase são reconstruídos toda vez

Olá a todos, estou trabalhando em um pequeno hack https://github.com/yarnpkg/yarn/pull/5314.
A ideia é armazenar em cache um pacote integrado em um espelho offline para evitar a execução de scripts de instalação o tempo todo.

Portanto, se você usar offline-mirror e executar yarn add node-sass :

1. yarn iria construir e instalar node-sass como de costume
2. depois que os scripts de instalação forem executados, ele irá gerar node-sass-v4.7.2-darwin-x64-57.tgz da pasta node_modules/node-sass modificada
3. Da próxima vez que você executar yarn install na mesma plataforma, ele apenas descompactará node-sass-v4.7.2-darwin-x64-57.tgz vez do original e não executará scripts de instalação

Isso não funcionará para todos os casos, mas pode ser uma solução para sistemas de CI off-line em que você não deseja que os pacotes cheguem à Internet e executem os mesmos scripts de instalação todas as vezes.

Estou tentando instalar o typescript como um pacote global, e o yarn passa o tempo todo reconstruindo coisas em vez de instalar o que realmente preciso agora.

Mudei para o fio pensando que é mais rápido e melhor. Eu removi qualquer vestígio de npm (exceto o que vem com a instalação do nó); e reinstalado todos os pacotes globais para yarn.

Yarn agora está testando minha paciência, fazendo-me esperar de 1 a 15 minutos pela instalação simples do pacote. O Yarn deve ser mais inteligente o suficiente para instalar o que é pedido primeiro antes de reconstruir outras coisas, a menos que o pacote solicitado dependa explicitamente de qualquer um dos pacotes nativos que requerem reconstrução.

Meio Ambiente:

• Nó: 9.4.0
• Fio (global): 1.3.2
• macOS Sierra: 10.12.6
• Macbook pro 15 polegadas
  
  
  
  • Memória: 16 GB
  
  
  • CPU: 2 GHz - Intel Core i7
  
  
  • Armazenamento: magentic (bastante espaço livre)
  
  
  • Aplicativos em execução no momento da instalação: Firefox (6 guias), Mail.app e iTerm (com 2 guias)
  
  

Histórico

A obtenção de pacotes leva muito tempo

script de atualização global de yarn
yarn global v1.3.2
[1/4] 🔍 Resolvendo pacotes ...
[2/4] 🚚 Buscando pacotes ...
[##################################################### ################ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

A vinculação de dependências está travada sem nenhum progresso por minutos

script de atualização global de yarn
yarn global v1.3.2
[1/4] 🔍 Resolvendo pacotes ...
[2/4] 🚚 Buscando pacotes ...
[3/4] 🔗 Vinculando dependências ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

Reconstruir todos os pacotes - leva muito tempo

script de atualização global de yarn
yarn global v1.3.2
[1/4] 🔍 Resolvendo pacotes ...
[2/4] 🚚 Buscando pacotes ...
[3/4] 🔗 Vinculando dependências ...
[4/4] 📃 Reconstruindo todos os pacotes ...
[12/17] ⠐ websocket
[2/17] ⠐ expresso: verificando opção do gcc para aceitar ISO C99 ...
[8/17] ⠐ porta serial: usando [email protected] | darwin | x64
[17/06] ⠐ agora:> Para o código-fonte, confira: https://github.com/zeit/now-cli

script de atualização global de yarn
yarn global v1.3.2
[1/4] 🔍 Resolvendo pacotes ...
[2/4] 🚚 Buscando pacotes ...
[3/4] 🔗 Vinculando dependências ...
[13/17] ⠈ sem servidor
[13/17] ⠂ sem servidor
[14/17] ⠠ solgraph
[14/17] ⠁ solgraph
[14/17] ⡀ solgraph
[- / 17] ⠈ esperando ...
[- / 17] ⠄ esperando ...
[- / 17] ⠠ esperando ...
[- / 17] ⠈ esperando ...
[- / 17] ⠄ esperando ...
[- / 17] ⢀ esperando ...
[- / 17] ⠈ esperando ...

Eu continuo esperando :-)

outro efeito colateral é que as bibliotecas que baixam e armazenam em cache as pré-compilações também são apagadas e precisam ser baixadas novamente: especificamente o cache de nwjs-builder-phoenix de SDKs de destino

1. O pacote nativo é sempre reconstruído ao atualizar uma versão de pacote que não seja nativo.

O yarn armazena em cache o binário para o global, como npm?

Começo a me frustrar um pouco ter que reconstruir nwjs em cada instalação simples. Não faz sentido

estou vendo isso também. O uws é reconstruído sempre que eu faço uma operação de adicionar / remover. fio v1.3.2

Olá, @bestander. Tentamos # 5314 no monorepo de nossa empresa, mas não teve nenhum efeito em parar as reconstruções de algumas dependências para nós. Ativamos yarn-offline-mirror e pack-built-packages em .yarnrc conforme mostrado nos testes adicionados.

O ponto crucial é que executar yarn sempre leva cerca de 40-50 segundos para nós, mesmo se o comando que executamos diretamente antes também fosse yarn .

@ bazyli-brzoska, mudei o sinalizador para ficar mais explícito e esqueci de atualizar a descrição.
Você pode tentar com a sinalização experimental-pack-script-packages-in-mirror definida como "verdadeira"?

Existe algum progresso nisso? Vejo que a solicitação pull já está mesclada e está na versão 1.5.1 mais recente. Estou no 1.5.1 e nada mudou para mim. No entanto, estou pensando em voltar para o npm, porque esperar 322.70s ou 282.69s ou mesmo 683.41s (esses são realmente meus últimos três yarn add s) por instalar um pequeno plugin de rollup ou lodash ou bem, praticamente qualquer coisa, é simplesmente insano.

Seria ótimo se advertências importantes como essas estivessem em seu README.md. Os usuários instalam o yarn porque é supostamente "mais rápido" e fazer essa transição do npm para o yarn não é um passo pequeno, então seria bom se houvesse algum aviso prévio para os desenvolvedores, para que eles possam pensar sobre isso mais uma vez, antes de converter seus scripts, poluindo seus globais e aprendendo o fio cli.

Achei que fosse apenas um problema da minha velha máquina de 32 bits, mas depois de ver a 237ª vez acontecer, pesquisei no Google e, ah, o fio não é mais rápido. Ótimo.

Desculpe por provavelmente ser mau, mas acho que você entendeu a frustração.

Aceitamos contribuições.

Dito isto, algo para se manter em mente com relação aos pacotes que são reconstruídos quando não "precisam": etapas de construção são executadas após as dependências serem instaladas. O que significa que os scripts de construção têm permissão para usar essas dependências. O que significa que se essas dependências mudarem por qualquer motivo (o que pode ocorrer 'aleatoriamente', por exemplo, se otimizamos duas versões compatíveis de um pacote em uma), então precisamos executar novamente as etapas de construção, mesmo que essas dependências não sejam realmente usado durante a construção (porque como poderíamos saber?).

Portanto, não é exatamente um problema fácil. Pelo menos parte do problema vem do próprio design package.json. Conte-me sobre a frustração 🙂

@arcanis não entendi esta parte:

mesmo se essas dependências não forem realmente usadas durante a construção (porque como poderíamos saber?).

Eu pensei que o design do YARN era para manter dependências estáticas + versão (yarn-lock) e, portanto, não haverá "atualizações" aleatórias.
Mesmo assim, o pacote json dá uma árvore completa, então por que você diz "como poderíamos saber"? Uma vez que a árvore esteja resolvida, é realmente fácil dizer se alguma das dependências (mesmo as de nível profundo) para construir o X mudou ou não.

Digamos que eu tenha uma dependência foo que depende de babel-core e left-pad@^1.0.0 , e que esta dependência foo tem um script de construção que executa o babel em seu arquivo de índice .

Depois de executar yarn add foo na pasta do meu projeto, acabo tendo [email protected] no node_modules, certo? Agora, digamos que uma nova versão do teclado esquerdo seja lançada ( 1.1.0 ) e eu queira usá-la em meu projeto. Vou executar yarn add left-pad , que irá então resolver para latest , ou seja, 1.1.0 .

Agora o que pode acontecer é que Yarn "verá" que há duas cópias do botão esquerdo na árvore e também verá que eles podem ser otimizados: afinal, foo depende de left-pad@^1.0.0 , então 1.1.0 é compatível. Portanto, ele removerá a versão anterior e usará apenas 1.1.0 . Como a dependência mudou, precisamos executar o script de construção novamente porque Yarn não tem como saber que left-pad é uma dependência de tempo de execução em vez de uma dependência de tempo de construção .

Agora você pode perguntar "mas por que não pular a reconstrução quando as dependências transitivas forem alteradas?". A resposta é que alguns pacotes (em particular os pacotes nativos) têm dependências que afetam radicalmente como são construídos. Quando isso acontecer, realmente queremos reconstruir esses pacotes, ou acabaríamos com artefatos incompatíveis.

@arcanis , acho que você entendeu mal o problema. o problema aqui é que esses pacotes nativos estão sendo reconstruídos _ toda_ vez, mesmo quando yarn é executado duas vezes (ou mais) em rápida sucessão. não tem _nada_ a ver com atualização de dependências - ele _sempre_ reconstrói.

@Spongman Concordo com seu último comentário. Mas, como @Spongman mencionou corretamente, a reconstrução sempre acontece . Mesmo se você fizer apenas yarn && yarn - você terá duas reconstruções completas , apesar do fato de nada ter mudado na estrutura de dependência.

Tentei executar yarn add leveldown bcrypt && yarn && yarn como no OP e só consegui uma compilação: / Você tem um comando que eu possa usar para reproduzir esse comportamento?

Você pode tentar, por exemplo:

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)

(isso está no Ubuntu 14 LTS)

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

yarn & yarn 

Não está causando duas reconstruções, mas o exemplo com o socket.io, adicionando react, removendo react está causando duas reconstruções

Tentei o exemplo socket.io com yarn v1.5.1 e não obtive reconstruções ao usar o novo recurso para armazenar em cache compilações nativas. Para fazer isso, você precisa usar o cache offline. No meu ~/.yarnrc eu tenho:

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

Quando tento como outro usuário sem essa configuração, ele ainda reconstrói todas as vezes.

Sim, nenhuma reconstrução agora quando adicionadas essas opções.
Mas se apenas experimental-pack-script-packages-in-mirror true , ele ainda reconstrói.
Por que não definir yarn-offline-mirror para um caminho padrão como "~ / .yarn / cache".

Ainda experimental, mas é uma sugestão interessante (cc @bestander). Acho que o problema que tenho com isso é que, pessoalmente, não gosto da ideia de habilitar coisas sem o consentimento explícito do usuário. Também tem outras implicações: o que significaria ter yarn-offline-mirror definido como false e experimental-pack-script-packages-in-mirror como true ? experimental-pack-script-packages-in-mirror substituir as configurações de yarn-offline-mirror ? Um pouco confuso.

Dito isso, o bug de reconstruir uws ao adicionar left-pad é um tanto chato, de fato, e as configurações de experimental-pack-script-packages-in-mirror são apenas uma solução alternativa. Não tenho certeza se terei largura de banda para analisar isso na próxima semana ou depois, mas se alguém estiver interessado em consertar, isso seria bastante impactante.

@arcanis Obrigado pela amável resposta. A frustração vem da forma como o fio é apresentado. No momento, não é apenas "rápido", definitivamente não é mais rápido que o npm e meio que inutilizável em projetos do mundo real. Imho, deve haver uma informação sobre isso ou até mesmo a solução alternativa por @skomorokh em seu arquivo README.md até que isso seja corrigido. Ou apenas remova o "rápido" da sua descrição.

Eu sentiria a mesma frustração se o readme do angularjs repo declarasse que é um framework leve. Simplesmente não é.

Sempre repita para baixar o arquivo binário após 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

Vou tentar depurar um pouco isso hoje. Eu acho que na verdade pode ser tão simples quanto PackageInstallScripts não verificar pkg.fresh para apenas reconstruir pacotes recém-instalados. Em vez disso, parece que está apenas passando por todos eles.

Depois de mexer um pouco, estou começando a pensar que reconstruímos as coisas o tempo todo caso alguém rm -rf node_modules ou o módulo seja excluído de lá.

Temos uma lista de artefatos de construção detectados no arquivo .yarn-integrity , então estou pensando que uma reconstrução só deve ocorrer se fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

Portanto, é um pouco mais envolvente do que eu pensava.

Acabei de yarn add ed moment , um pacote de dependência zero, para meu aplicativo de reação atualizado, levou 377.97s .

Fiz de novo logo depois disso, pegou 389.63s e reconstruiu os binários novamente.

Apenas para comparação, apaguei node_modules e inseri npm install :
added 1751 packages and updated 124 packages in 360.595s

Voltou para npm agora.

OK, mais algumas informações para todos os olhos sobre este assunto ... Estou mexendo nisso há um dia e meio e finalmente percebi algumas coisas.

Primeiro, a maioria desses problemas de reconstrução são corrigidos. Já existe um código em PackageInstallScripts que apenas reexecuta os scripts de instalação de um pacote se estiver marcado como "fresco" :

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

Por exemplo, se você usar node-sass :

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

Além disso, yarn install s consecutivos não são reconstruídos.

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

... mas é claro que existem algumas exceções ...

Em um yarn remove o sinalizador force é definido (para corrigir algum outro bug, suponho, mas é assim há mais de 2 anos), portanto, as reconstruções sempre ocorrem.

No entanto, isso é indiscutivelmente "correto" porque é o que o npm também faz:

~/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

Você pode ver que em uninstall de left-pad , npm executou os scripts install e postinstall para node-sass .

O pacote uws (que é usado por alguns outros pacotes, como socket.io , browser-sync , etc ...

algo durante o processo de instalação altera um dos arquivos (o tamanho e o carimbo de data / hora são 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 vê um arquivo que foi "alterado" em comparação com o cache, então marca o pacote como "novo" para reinstalação

Isso então aciona a lógica acima, que reexecuta os scripts de instalação porque está "fresco". Yarn está tentando ser útil e "consertar" os arquivos incorretos, mas é claro que não sabe que o arquivo foi alterado devido ao script de instalação. Podemos ter que investigar alguma forma de consertar isso, mas também se fala em mudar a forma como esses arquivos são comparados (pare de executar o stat em todos os arquivos), então isso pode ser resolvido com esse retrabalho.

Esperançosamente, isso explica alguns dos casos aqui em que algumas pessoas dizem que funciona e outras dizem que não.

Obrigado por mergulhar mais fundo aqui, @ rally25rs.

1. Re: usando force no comando delete.
   Essa foi claramente uma correção rápida de bug que alcançou a correção com uma abordagem nuclear IIRC https://github.com/yarnpkg/yarn/pull/323.
   Não deve ser difícil remover force e contornar o problema.

2. node_modules/uws/uws_darwin_57.node : este arquivo deve estar no campo artifacts de .yarn-integrity e então uws não deve ser marcado como não atualizado durante a vinculação.
   Provavelmente algo está errado aqui

@bestander ah bom argumento sobre 2. Vou tentar ver se há uma maneira sensata de trabalhar isso no cheque.

@stereokai Em meu comentário acima, observo que o npm também reconstrói pacotes na desinstalação / remoção, então esse caso é indiscutivelmente "correto" se você considerar o comportamento do npm o padrão.

@ rally25rs Obrigado por apontar isso :)

No entanto, considero esse comportamento problemático, independentemente do gerenciador de pacotes. É difícil entender por que esse tipo de comportamento é necessário para uma operação correta. Seu SO não reinstala programas locais quando você adiciona / remove outro, porque os aplicativos já estão lá. Eu não esperaria mais nada de um gerenciador de dependência estática, nahmean?

@stereokai Concordo de certa forma, e é por isso que usei a frase "indiscutivelmente correto" 😆
Seu sistema operacional também não muda onde outros aplicativos são instalados quando você desinstala um não relacionado.

Suponha que você tenha alguma árvore de dependências como:

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

Se você instalar isso, ele formará a mesma estrutura de diretório em node_modules , porque não pode içar depB para a raiz.

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

Mas de você yarn remove depB , a nova estrutura de depósito é:

myProj
  |- depA v1
       |-depB v2

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

portanto, o diretório atual onde depB v2 está instalado pode mudar sempre que um pacote é adicionado ou removido. Esses diretórios não são apenas copiados de um local para outro. O antigo é excluído e o novo é copiado do cache para o novo destino, o que significa que os artefatos de construção que estavam em node_modules/depA/node_modules/depB não existiriam mais e precisariam ser reconstruídos em node_modules/depB .

Da mesma forma, yarn add [email protected] mudaria o caminho onde depB v2 está instalado (na verdade, devo testar se meu PR para não reconstruir em yarn add realmente funciona neste caso)

Suspeito que seja por isso que esses pacotes são sempre reconstruídos.

A mudança real aconteceu neste commit: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
em 2016. O arquivo era denominado uninstall.js na época, mas force: true foi adicionado aos sinalizadores passados ​​para install . Não parece haver nada específico no comentário de confirmação para indicar _why_.

Seria incrível se houvesse uma maneira de evitar as reconstruções em pelo menos _alguns_ casos.

Qualquer pessoa é bem-vinda para trabalhar em um RP. 😸Como indiquei acima, reconstruções já não acontecem em yarn install e yarn add (na maioria dos casos). Eu abri o # 5470 que deve eliminar reconstruções desnecessárias para yarn add quando você tem uws em suas dependências (ou outros pacotes que alteram seus próprios arquivos durante a instalação). O único caso restante que conheço é yarn remove .

Depois de ter lido a maior parte deste tópico, não entendo o que está acontecendo aqui.

Tenho vários pacotes nativos sendo reconstruídos sempre que uso yarn add para qualquer outro módulo (não relacionado). Demora cerca de 20 minutos de uma carga muito alta nas CPUs do meu laptop. Eu simplesmente não consigo trabalhar dessa maneira.

Aparentemente, a partir deste tópico, é um problema há 19 meses.

É um bug? Está sendo trabalhado? Existe uma solução alternativa? Devo voltar para o npm?

Devo voltar para o npm?

sim, até que # 5470 seja lançado.

@vibl

Aparentemente, a partir deste tópico, é um problema há 19 meses.

Na verdade, foi corrigido (principalmente) há muito tempo. Este tópico permanece aberto para um caso extremo que encontrei há algumas semanas, onde o yarn reconstruirá um pacote se esse pacote alterou qualquer um de seus arquivos (ele pensa que o arquivo está errado em comparação com o que estava no download original, então quer consertar isto). E para alguma discussão aberta sobre se remove e upgrade deveriam fazer uma reconstrução (faz no npm, mas talvez não deva)

É um bug?

Talvez. Quais pacotes estão sendo reconstruídos? O único que conheço que é um problema constante é uws , portanto, saber mais seria útil.

Está sendo trabalhado?

O caso específico que mencionei acima foi corrigido em # 5470

Existe uma solução alternativa?

Se o pacote que você está adicionando não tem scripts de instalação, você pode usar --ignore-scripts

Ou você pode verificar o ramo do PR acima e usá-lo.

Demora cerca de 20 minutos

Uau. Estou curioso para saber que pacote é esse.

Obrigado por responder.

Os pacotes noise-search , level-rocksdb e jq recompilam cada vez que adiciono qualquer pacote não relacionado com yarn add . Meu laptop é um pouco antigo, por isso leva muito tempo para compilá-los ao mesmo tempo.

Usei o Yarn 1.5.1 e o node 9.8.0.

@vibl yeesh, noise-search é definitivamente o culpado por trás das compilações longas ...

~/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.

mais de 7 min em um MacbookPro 😢

De qualquer forma, instalei noise-search e executei yarn add left-pad com o código de # 5470 e _não_ causou uma reconstrução, então acho que você deve estar pronto para prosseguir assim que tivermos essa fusão 👍

Obrigado :-)

Devo verificar novamente o Yarn em alguns dias, algumas semanas ou alguns meses?

Acabei de descobrir que esse bug, com o mesmo projeto exato no mesmo laptop (dual boot), não ocorre no Windows 10. Mas está lá nas três últimas versões do Debian, Ubuntu, Arch Linux e Fedora. Esquisito. Ainda não experimentei o MacOS, mas parece que algumas pessoas também têm problemas nele.

@vibl Não tenho certeza de quando será nosso próximo lançamento (não estou envolvido nesse planejamento)

@nnmrts sim, descobri que é uma coisa específica do sistema operacional. Dos meus comentários em # 5470:

no linux com nó 8, quando os arquivos são copiados do cache para node_modules, os timestamps são atualizados. yarn decide que os arquivos são diferentes e marca a referência nova.
No entanto, isso só parece acontecer no nó 8 do linux.
isso ocorre porque o Node v8.5 introduziu fs.copyFile, que tornava as cópias muito mais rápidas. IIRC que direciona para a cópia do sistema de arquivos nativo, de modo que explicaria por que funciona de maneira diferente nos sistemas operacionais e apenas no nó 8.

@ rally25rs @nnmrts Definitivamente, não é uma coisa específica do MacOS. Também acontece no meu PC Win10

@stereokai Bem, todo esse problema não é específico. Às vezes, os pacotes precisam ser reconstruídos e as pessoas ainda pensam que é um bug e postam aqui. Sem um repositório reproduzível sólido para cada sistema operacional, não podemos saber de nada.

O armazenamento em cache local de módulos construídos (de # 5314) pode ajudar ?:

Adicione .yarnrc ao seu projeto com o seguinte:

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

Após a primeira instalação, os módulos pré-construídos ficarão em ./<your-offline-mirror-path>/prebuilt . yarn.lock também é atualizado com variantes pré-construídas

Extraiu o último 66a0143a753cd4ade1a0fffee2174890d564c129 e parece estar funcionando corretamente😎

AINDA baixe o binário repetidamente.

• nó v6.13.1
• yarn 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

Em quinta-feira, 29 de março de 2018 às 2h30, Andrew Lane [email protected]
escrevi:

Cache localmente de módulos construídos (de # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) pode ajudar ?:

Adicione .yarnrc ao seu projeto com o seguinte:

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

Após a primeira instalação, os módulos pré-construídos viverão em
.// pré-construído. yarn.lock também é atualizado
c / variantes pré-construídas

Puxou o último 66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
e parece estar funcionando corretamente😎

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

@snowyu você excluiu yarn.lock, node_modules e yarn cache clean ? ./Yarn-offline-mirror/prebuilt é preenchido após a instalação?

É um novo projeto em temp. Sim, posso ver o arquivo node-sass-4.8.3.tgz na pasta de cache.
Agora, eu corro yarn cache clean . MAS AINDA baixe o binário repetidamente * .

`` `bash

yarn init -y
fio adicionar nó-sass
yarn add v1.6.0-20180327.1507
info Nenhum lockfile encontrado.
[1/4] Resolvendo pacotes ...
[2/4] Buscando pacotes ...
[3/4] Vinculando dependências ...
[4/4] Construindo novos pacotes ... Baixando o binário de https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
arquivo de bloqueio salvo com sucesso.
sucesso Salvou 152 novas dependências.
Feito em 11.98s.

fio adicionar nó-sass
yarn add v1.6.0-20180327.1507
[1/4] Resolvendo pacotes ...
[2/4] Buscando pacotes ...
[3/4] Vinculando dependências ...
[4/4] Construindo novos pacotes ... Baixando o binário de https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
arquivo de bloqueio salvo com sucesso.
sucesso Salvou 1 nova dependência.
info Dependências diretas
└─ [email protected]
info Todas as dependências
└─ [email protected]
Feito em 13.45s.
``

OK, fiz um repositório git simples para reproduzir esse bug.

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

yarn realizar reconstrução desnecessária ttf2woff2 quando tento adicionar dependência zero 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 ... ]

Posso reproduzir isso no sistema OSX host e no contêiner do docker com a imagem node mais recente

O NPM funciona corretamente neste 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 ... ]

Minha versão do fio 1.5.1

@vlmonk isso ainda acontece se você clonar https://github.com/rally25rs/yarn de @ rally25rs e usar o código em # 5470 (branch fix-linking-rebuilding-uws-932 )?

@karlhorky sim, o fio ainda reconstrói ttf2woff2 após adicionar left-pad

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

O pacote ttf2woff2 vem com arquivos que são alterados na etapa de construção. Na próxima execução, o yarn vê esses arquivos alterados e reinstala o pacote.

O Yarn deve lidar melhor com essa situação: ele deve ver que esses arquivos foram alterados durante a etapa de construção e deve aceitar esses arquivos alterados como os arquivos "corretos", não tratá-los como um motivo para uma reinstalação.

Eu verifiquei isso com registro adicional (https://github.com/sth/yarn/tree/trace-rebuild). Na primeira instalação, mostra:

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

O arquivo de pacote https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz de fato contém esses arquivos.

Vemos isso com o OS X também, adicionar qualquer pacote com yarn add aciona uma recompilação de quaisquer pacotes dependentes. Temos um pacote node-gyp com código nativo, leva mais de 1 minuto cada vez que outro pacote é adicionado e ainda não há muito código no módulo nativo (ficará muito pior). Isso é com fio 1.5.1.

Estamos usando yarn add ../a com caminhos relativos, se isso fizer diferença.

Informe-nos se houver alguma solução alternativa ou quando será corrigido.

Isso é com fio 1.5.1.

Esse problema foi corrigido no 1.6.0, que foi lançado recentemente.

Ainda vejo isso com 1.6. Desde que mudou de npm para yarn há muito tempo atrás uws como sempre reconstruído (ou pelo menos yarn ficou preso em uws por aproximadamente 5-10 segundos).

Passos para reproduzir:

1. $ yarn desatualizado
2. escolha um pacote desatualizado
3. $ yarn upgrade [pacote]

@grantila, você pode fornecer um package.json completo ou repo com etapas que reproduzem isso com Yarn 1.6.0 ?

isso ainda está acontecendo em 1.6.0

você pode reproduzir isso usando https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784

Eu tenho um projeto simples e estou vendo isso também. Adicionar ou remover um pacote parece desencadear uma reconstrução completa de pelo menos um pacote a 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"
  }

Depois que eles foram instalados, adicionei o pacote unescape , que desencadeou uma reconstrução de sodium . Em seguida, removi-o, o que desencadeou uma reconstrução do que parecia ser cada pacote que precisava ser compilado. Adicionar este pacote simples demorou 36s e removê-lo demorou 100s!

EDIT: usando Node 8.11.1 e yarn 1.6.0 no Debian Stretch.

@arcanis @ rally25rs por favor reabra o problema, vários relatos sobre isso ainda acontecendo, mesmo com a correção combinada.

Eu acho que isso é mais um problema de @ rally25rs :)

@grantila e upgrade _sempre_ reconstruirá tudo. Isso é intencional. O npm faz a mesma coisa (menciono isso em um comentário em algum lugar deste longo tópico), embora possamos potencialmente tentar parar de fazer isso. Não tenho certeza de que repercussões isso pode ter.

Todos os outros:

Em # 5680, aponto que isso ainda acontece se um pacote deleta seus próprios arquivos _ (por que eles fazem essas coisas?) _ E o yarn não rastreia isso em nenhum lugar (rastreamos quais arquivos são criados ou modificados), então ele apenas pensa que estão faltando arquivos no pacote e o reconstrói.

Suponho que possamos reabrir isso, mas isso foi corrigido para a maioria dos pacotes. Se alguém quiser adicionar "eu também" a isso, _por favor_ forneça seu package.json ou mencione especificamente qual pacote está sendo reconstruído continuamente, já que você pode ter algumas dependências que reconstroem e outras não.

Qualquer pessoa é bem-vinda para fazer um RP disso! (veja meus comentários de depuração em # 5680)

Desculpe por adicionar mais ruído, mas eu gostaria de sugerir que você bloqueie este problema e aponte para um novo com as informações mais recentes no topo.

Acho que o problema aqui mudou um pouco e está pelo menos parcialmente resolvido. Com todas as postagens aqui, é difícil para alguém novo se atualizar sobre o que foi corrigido e o que ainda é um problema.

Eu concordo com @ james-rabbit

Sim, você está certo. Vou bloquear este para que a resposta de @rally25rs fique visível.

Se você tiver problemas com pacotes nativos:

• Se isso acontecer com todas as dependências nativas, abra um problema genérico. Este problema deveria ter sido resolvido, então não espero ver nenhum em breve - ainda assim, se você puder fornecer etapas de reprodução, sinta-se à vontade para abrir um novo problema (e você pode criar um link para este, se desejar).

• Se acontecer com uma dependência nativa