<p>a instalação do yarn trava durante "Buscando pacotes ..."</p>

Tenho o mesmo problema no Windows 10 usando nodejs v6.2.0 x64.

Ele trava ao buscar o último pacote:

C:\xxx>yarn
yarn install v0.15.1
info No lockfile found.
warning [email protected]: No license field
[1/4] Resolving packages...
warning wdio-mocha-framework > mocha > glob > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning wdio-mocha-framework > mocha > [email protected]: to-iso-string has been deprecated, use @segment/to-iso-string instead.
warning wdio-mocha-framework > mocha > [email protected]: Jade has been renamed to pug, please install the latest version of pug instead of jade
[2/4] Fetching packages...
█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ 868/869

@sorgloomer sim mesmo comportamento, na verdade está pendurado no último pacote.

Mesmo problema, mas com bower.json. Nesse caso, ele está funcionando no meu macOS local. (com uma complicação https://github.com/yarnpkg/yarn/issues/846)

{
  "name": "jaguar",
  "version": "0.0.0",
  "private": true,
  "dependencies": {
    "bootstrap": "~3.3.5",
    "devicejs": "2ae5c775e35ccc837589e5af34e292c54936778c",
    "jquery": "2.1.3",
    "jquery-transform": "e195b9a7118558bb1141e50b80380ea5f31dffb8",
    "moment": "2.14.1",
    "moment-timezone": "0.5.5",
    "owl-carousel2": "2.0.0-beta.2.4",
    "raven-js": "3.5.1",
    "ua-parser-js": "0.7.10",
    "underscore": "1.8.3",
    "object-fit": "~0.4.2",
    "picturefill": "^3.0.2",
    "jquery-selectBox": "316c77f157cb25c7a6ea36822143ac9d97845067"
  },
  "resolutions": {
    "jquery": "2.1.3"
  }
}

O mesmo problema aqui.
windows 10
nó v6.2.0
npm 3.8.9

yarn yarn install v0.15.1 info No lockfile found. warning [email protected]: No license field [1/4] Resolving packages... warning glob > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp.spritesmith > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. warning gulp-imagemin > imagemin-gifsicle > exec-buffer > execa > [email protected]: cross-spawn no longer requires a build toolchain, use it instead! warning gulp.spritesmith > spritesmith > pixelsmith > ndarray-fill > cwise > static-module > through2 > xtend > [email protected]: [2/4] Fetching packages...

Mesmo problema aqui
Windows 10
nó v6.2.0
npm 3.8.9
[email protected]
Usando nvm para atualizar ou instalar versões de nó

Funciona no Windows 10 com
nó 6.7.0
npm v3.10.3
[email protected]
Portanto, parece ser a versão do nó ou npm que é conflitante

Achei que o objetivo era excluir o cliente npm da equação

Atualizar para nodejs v6.7.0 resolveu meu problema

Quebrado no nó v4, funcionando na v6.7

aguenta:

• Nó 5.11.1
• npm 3.8.6
• macOS 10.12
• fio 0.15.1

aguenta:

• node v6.7.0
• windows 10
• yarn 0.15.1

Minha máquina jenkins também estava vendo o mesmo hang-on-final-package-install, com:

• node v5.11.0
• Ubuntu 14.04.2 LTS
• fio 0.15.1
• npm 3.10.8

Atualizar para o nó 6.8.1 por meio de n corrigiu magicamente.

Confirmado. Permanece no 6.1.0 e a atualização para 6.8.1 corrigiu o problema.

(O mesmo aqui - Nó 6.2 -> 6.8 corrige)

Falhando para mim no CircleCI:

• Ubuntu 14.04 (confiável)
• Node v4.4.6
• fio 0.16.1
• npm não executado neste env.
• Cache / node_modules são apagados via rm -rf node_modules/ && rm -rf ~/.yarn-cache/ && mkdir -p ~/.yarn-cache

Em particular, ele fica travado consistentemente em algum arquivo que está sendo retirado de um repositório git privado. O arquivo varia, mas é sempre aquele repositório.

Este comando mostra os descritores de arquivo abertos por um determinado processo:

$ lsof -p <pid of yarn.js process>
( ... results trimmed ... )
node    19551 ubuntu   24w   REG               0,89     2048  457983 /home/ubuntu/.yarn-cache/npm-our-private-pkg-1.0.0/src/styles/fonts/glyphicon.svg

Registrei um problema relacionado aqui nos fóruns do CircleCI com outras informações, provavelmente não mais significativamente valiosas do que as que estão aqui.
https://discuss.circleci.com/t/yarn-install-hangs-and-never-completes-related-to-dash/7664

Update: Updating to Node v6.9.1 resolve o problema em reconstruções repetidas com e sem cache.

Portanto, para resumir alguns dados aqui em uma curva para um solucionador de problemas:
Afeta todos os sistemas operacionais, ambos yarn 0.15.1 e 0.16.1, e parece estar quebrado no nó 6.2 (e anterior) e corrigido no nó 6.7 (e posterior), sem nenhum ponto de dados relatado no meio.

Isso parece acontecer comigo também.
Ubuntu 14.04
Nó 4.4.5
Fio 0.16.1

eu também, é uma merda
[email protected]
[email protected]
[email protected]

Mesmo problema aqui
Ubuntu 14.04
node v6.0.0
npm 3.8.6
[email protected]

Mesmo:

OSX: 10.11.6
Nó: v5.12.0
Fio: 0,17,9

Funciona com nó> 6,7

Também trava para mim em 1040/1041
Windows 10
Node v6.9.3
Fio 0.18.1

Eu apenas corri para isso.

Nó 7.4.0
npm 3.10.9
fio 0,18.1

Atualização: descobri que se você deixá-lo assentar por cerca de 8 minutos, ele acabará passando ...

Datapoint: Já estou pendurado há 2 dias. O processo não estava fazendo nada útil: https://gist.github.com/benlangfeld/24f704753d1564d2db102f972d066008

Eu descobri meu problema, mas pode ser específico para apenas algumas pessoas.

Estou no windows 10

vanilla-masker foi incluído para ser baixado pelo yarn, mas vanilla-masker é incompatível com o Windows devido a um diretório mal nomeado. Mudei a dependência para usar lagden-vanilla-masker (https://www.npmjs.com/package/lagden-vanilla-masker), uma cópia do vanilla-masker que renomeou o diretório ofensivo para ser compatível com o Windows.

Meu problema acabou sendo uma condição de disco cheio.

O que funcionou para mim foi sair da VPN:

antes de:

λ bundle → λ git develop* → yarn add winston-aws-cloudwatch
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error Command failed.
Exit code: 128
Command: git
Arguments: clone git://github.com/realtymaps/ssh2.git /Users/Justin/Library/Caches/Yarn/.tmp/f5257a9a008d54d3956928f15f351a79
Directory: /Users/Justin/Projects/www/MotorTrend/OnDemand/api/assets/bundle
Output:
Cloning into '/Users/Justin/Library/Caches/Yarn/.tmp/f5257a9a008d54d3956928f15f351a79'...
fatal: read error: Operation timed out
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

depois de:

λ bundle → λ git develop* → yarn add winston-aws-cloudwatch
yarn add v0.18.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning Unmet peer dependency "request@^2.34".
warning Unmet peer dependency "request@^2.34".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 19 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]
✨  Done in 16.95s.
λ bundle → λ git develop* →

Tendo o mesmo problema no macOS por um longo tempo, ele desacelera aleatoriamente em "Buscando pacotes". Para minha configuração, leva de 2 a 4 minutos em média, mas a cada duas execuções é de 35 a 30 minutos.

npm: 4.0.5
nó: 7.4.0
fio: 0,19,1

Tive esse problema no travis ao adicionar uma dependência github :(

samesies:
OSX 10.12.2
$ node -v
v6.5.0
$ npm -v
3.10.6
$ yarn --version
0,17,8

Para mim, a solução foi usar "npm install -g yarn" em vez de "apt-get install yarn"

Atualização: trava novamente, então npm install não foi uma solução e funciona às vezes. Acho que funciona com a versão 0.19.0, mas não 0.19.1 ..

Congelado para mim. Até tentei com "npm install -g yarn". Por favor conserte!!!

Versão do fio:
0,19,1

Versão do nó:
4.4.6

Plataforma:
linux x64

também experimentando isso, em vários arquivos de projeto / yarn, após a atualização para o yarn 0.19.1 por meio de npm i -g yarn@latest

fio 0.19.1
nó 6.1.0
Mac OS

para mim, fazer downgrade via npm i -g [email protected] funcionou para yarn install

Isso está acontecendo comigo em nossos servidores de teste, que acabaram de ser instalados mais recentemente.

fio 0.19.1
nó 5.11.1
ubuntu

EDIT: mesmo problema em 0.19.0 e no nó 5.12.0

EDIT 2: atualizado para o nó 6.9.5 e agora funciona

EDIT 3: atualizado para o yarn 0.19.1 novamente e ainda está funcionando

nó 6.1.0 => 7.2.1 funciona

Aconteceu comigo também. Trava na última dependência.
Nó: v5.12.0
Yarn: v0.20.3
Ubuntu 14.04

CORREÇÃO: Nó atualizado para a versão mais recente (v7.5.0) e funcionou.

Está tendo esse problema ultimamente, alguma resolução real?

Não, apenas sendo ignorado como de costume quando grandes empresas fazem um projeto de código aberto. Se funcionar para eles, então quem se importa se algo assim acontecer.

Contribua com uma correção ou dê uma caminhada @robclancy

lmao Eu amo essa lógica ... se algo é open source, não importa quantos bilhões de dólares as empresas estão por trás disso com um problema que as pessoas vêm repetidamente sem resposta, os fanboys irão defendê-lo cegamente.

É angular e seus documentos quebrados de novo.

Vá fanboy para outro lugar.

Você é um tolo se pensa que eu poderia ser fanboy de qualquer coisa escrita em JavaScript. Mas é claro que você está aqui apenas para trollar, não para contribuir com nada significativo. Você provavelmente pode esperar que esse problema seja bloqueado em breve.

Na verdade, eu estava aqui reclamando de um problema que deveria ter uma solução ou pelo menos uma resposta agora, como outros. Você está aqui para discutir com alguém na internet como um pequeno fanboy.

Que tal você consertar isso ou dar uma caminhada.

Outros são ela para perguntar educadamente sobre o progresso potencial no assunto. Fios nunca foram vendidos para você, portanto, fique reclamando para si mesmo. Você está sendo "aquele cara" que torna o código aberto um pé no saco.

Que irônico.

Você é um desses heróis de código aberto. Vá em frente, tenho certeza de que há outra biblioteca sendo negligenciada que você pode defender cegamente. Vá embora, herói. Você trabalha.

Eu contribuiria e ajudaria totalmente, mas estava olhando o código-fonte e estava legitimamente confuso sobre por onde começar.

Existem projetos para os quais posso contribuir com código e tendo a preferir esse caminho. Existem outros projetos em que posso apenas relatar um problema e espero que alguém que tenha mais conhecimento sobre a base de código possa ajudar a encontrar a causa raiz.

Este é definitivamente o último hehe.

Vamos manter a civilidade @benjie @robclancy 🥇

Mesmo problema, trava no totalpackages - 1
ubuntu linux 4.4.0-64-genérico x86_64
nó 6.2

@ code-by Atualizar para o Node 6.8.1 ou superior parece corrigir esse problema para a maioria (mas não todas) as pessoas; tente. Não vejo o problema desde a atualização em outubro. O nó 7.6 tem suporte nativo para assíncrono / aguardar, se isso melhorar o negócio 😉

Vamos lá! Novo Mac. Nó e npm instalados pelo Homebrew. Ainda está pendurado no último pacote.
$ node -v v7.7.1
$ npm -v 4.1.2

É um tiro no escuro, mas também vi isso em um Mac se você tiver um pacote privado referenciado em seu package.json - ele parece travar, mas na verdade está pedindo sua senha de chaveiro para ssh. O glifo de entrada segura ( ) aparece na borda direita da barra de progresso, mas no terminal de um colega que estava praticamente invisível. Eu consertei executando ssh-add -K antes de executar yarn .

@jdelStrother era isso! Eu tinha uma referência de pacote privado e ssh-add -K && yarn install é o comando que o fez funcionar. Obrigado e meu agradecimento, senhor!

Então, nossos problemas com isso foram embora para nós localmente, mas ainda tenho
usando NPM em CI porque isso acontece às vezes. Com os últimos comentários
sobre o ssh, decidi verificar e alterar qualquer um com https . Eles eram apenas
repositórios públicos do github, então nunca precisei do ssh, mas pensei que se o ssh mudasse
poderia resolver isso, talvez fosse um problema com SSL. E mudando aqueles
pacotes para uma versão e outra usando as definições do github em vez de
um URL https e a primeira execução não travou.

Na sexta-feira, 3 de março de 2017 às 4h30 DouG Molidor [email protected]
escreveu:

@jdelStrother https://github.com/jdelStrother era isso! eu tive um
referência de pacote privado e ssh-add -K && yarn install é o comando
que funcionou. Obrigado e meu agradecimento, senhor!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/764#issuecomment-283737992 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AA0UF5PKUy1Lx5nlGZF9HMoSIPhEG8-Tks5rhwrOgaJpZM4KUM4j
.

O mesmo aqui para CircleCI com Ubuntu 14.04 (Trusty) e node v6.9.1.

Corrigi o problema em https://github.com/yarnpkg/yarn/pull/2950. Houve um tempo limite ausente.

Estou surpreso com quanto tempo foi desperdiçado em discussões quando era literalmente uma correção de uma linha, contando que eu não sou do Javascript.

Tive o problema ao usar apenas o Node 5.12.0. Mudar para a versão 6.9.1 do Node (via nvm ) corrigiu o problema para mim.

Ele não deve ser afetado pela versão do Node porque a causa do problema é o tempo limite não especificado. # 2950 adiciona o tempo limite.

Então, quando o tempo limite ocorre, o yarn tenta novamente e busca em outros servidores? É por isso que o tempo limite é considerado a solução para os travamentos?

O Yarn tenta novamente todas as solicitações que falharam devido a erro de rede. Este PR faz com que Yarn considere o erro de tempo limite como um erro de rede. Não há "outros servidores", mas você pode ter mais sorte na próxima tentativa se for um erro de conectividade entre o local onde seu aplicativo está hospedado (EC2) e o CDN na frente de registry.yarkpkg.com

apt-get update está congelando para sempre quando eu tenho 'deb https://dl.yarnpkg.com/debian/ stable main' em meu sources.list :( - alguma solução?

Ainda tenho esse problema com yarn v0.23.2 e nodejs 6.1.0 . Atualizar para nodejs 6.7.0 resolveu o problema.

Eu também tenho esse problema com:
yarn v.0.23.2
nodejs v.7.9.0

e depois de tentar este comando:
fio adicionar semântica-ui

Esperei mais de duas horas e não terminou de instalar

Parece que a maioria dos casos é corrigida com uma atualização do Node.
Outra maneira de ajudar a depurar isso é executando com o sinalizador --verbose , para ver qual solicitação está pendurada.
Caso contrário, não tenho certeza se podemos fazer algo aqui

Você também pode usar strace para ver o que exatamente está pendurado.

Mesmo problema, tive nvm e mudaria as versões do nó para encontrar um que funcionasse.

Passou de 4.4.6 e 5.12 (sem sucesso). O node 6.7.0 funciona, mas é mais difícil convencer a equipe de que o yarn é um substituto imediato se tivermos que trocar as versões do node.

@jeffshek você pode tentar strace fio preso no nó 4.4.6 ou 5.12? Isso poderia nos ajudar a encontrar o problema.

Então, depois de mudar para o nó 6.7, fui capaz de instalar etc.

Para tentar recriar esse problema, limpei o yarn.lock, removi todos os node_modules e mudei para o nó 4.4.6.

eu estava conseguindo

yarn install

[2/4] 🚚  Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=6.0".
error Found incompatible module

Tudo bem, parece algum tipo de mensagem diagnosticável ... (Essa mensagem de erro estava apenas escondida o tempo todo?)

Mas agora, quando eu executo o yarn install, ele simplesmente magicamente ... funciona (nó 4.4.6). Portanto, agora, mesmo no nó 4.4.6, posso instalar o yarn muito bem com o mesmo package.json que não funcionava algumas horas atrás. Eu removi o yarn.lock, fiz uma nova instalação do fio e ele continua a funcionar.

Eu realmente gostaria de ter mais ajuda, mas usar o nvm para mudar para a versão 6.7 e depois voltar para a 4.4.6 fez o problema anterior desaparecer.

Eu sou novo no fio. Tentei pela primeira vez. Executou yarn install . Resultado: suspenso indefinidamente durante a instalação de pacotes. (Especificamente, o pacote jsesc , mas não tenho certeza se isso importa.)

Acontece que o yarn também estragou meus comandos NPM? o_O "npm clean" agora não funciona mais depois de um simples brew install yarn e yarn install . Isso é tudo que fiz em uma pasta de projeto, e meus módulos GLOBAL Node agora estão funcionando.

A versão do fio é 0.24.6
A versão do Node.js é 7.10.0

Desde a instalação do Yarn, o Node parece completamente quebrado.

_Update: eu finalmente consegui que o Node / NPM funcionasse novamente, mas o Yarn ainda trava._

Para mim, fica aqui indefinidamente:

Este parece ser um problema persistente. Sou capaz de reproduzir com:

[email protected]
[email protected]
[email protected]
[email protected]
amazon [email protected]
[email protected]
[email protected]

parece ter sucesso para o nó @> = 6.9.5

Pelo que eu posso dizer, o problema parece estar relacionado às dependências do repo do git devido a uma condição de corrida ao extrair o tar produzido a partir de git archive .

Fiz um repo que exibe o comportamento.
https://github.com/andrsnn/yarn-git-dependency-issue

Até agora rastreei o problema neste trecho de código localizado em ~/.yarn/lib-legacy/util/git.js

_cloneViaLocalFetched(dest) {
    var _this4 = this;

    return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
      yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
        cwd: _this4.cwd,
        process: function process(proc, resolve, reject, done) {
          const extractor = tar.Extract({ path: dest });
          extractor.on('error', reject);
          extractor.on('end', done);

          proc.stdout.pipe(extractor);
        }
      });
    })();
}

Nesta etapa, o repositório de dependência parece ter sido clonado com sucesso em uma pasta tmp /Users/andrsnn/Library/Caches/Yarn/.tmp/06cc8c2b5aba0eca42bd03dabc0d87f6 , extraindo para um destino em /Users/andrsnn/Library/Caches/Yarn/npm-yarn-dependency-a-1.0.2-fc796525f8a9e3130248520d386f9823502eb6cd . Não parece ser um problema de rede.

Ocasionalmente, o evento 'final' nunca é disparado do módulo node-tar . Parece estar pendurado em um emit de 'dados', que contém um pedaço trucado do arquivo yarn.lock da dependência git.

████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████░ 176/177{ '0': 'data',
  '1': <Buffer 30 2e 34 3a 0a 20 20 76 65 72 73 69 6f 6e 20 22 34 2e 30 2e 36 22 0a 20 20 72 65 73 6f 6c 76 65 64 20 22 68 74 74 70 73 3a 2f 2f 72 65 67 69 73 74 72 ... > }
0.4:
  version "4.0.6"
  resolved "https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb"

lodash.isstring@^4.0.1:
  version "4.0.1"
  resolved "https://registry.yarnpkg.com/lodash.isstring/-/lodash.isstring-4.0.1.tgz#d527dfb5456eca7cc9bb95d5daeaf88ba54a5451"

lodash.keys@^3.0.0:
  version "3.1.2"
  resolved "https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a"
  dependencies:
    loda

Para determinar o que precede, envolvi o emissor de evento:

_cloneViaLocalFetched(dest) {
    var _this4 = this;

    return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
      yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
        cwd: _this4.cwd,
        process: function process(proc, resolve, reject, done) {
          const extractor = tar.Extract({ path: dest });

          var timeout;
          function log(args) {
            return function() {
              console.log(require('util').inspect(args));
              console.log(args[1].toString());
            };
          }
          function debug(emitter) {
              var originalEmitter = emitter.emit;

              emitter.emit = function() {
                  console.log('eventName', arguments[0]);
                  clearTimeout(timeout);
                  timeout = setTimeout(log(arguments), 20000);
                  originalEmitter.apply(emitter, arguments);
              };
          }

          debug(extractor);
          extractor.on('error', reject);
          extractor.on('end', done);


          proc.stdout.pipe(extractor);
        }
      });
    })();
}

Isso pode muito bem ser um bug em node-tar ou uma dependência na qual ele depende.

Esperançosamente, outros podem lançar alguma luz sobre a correção. Estou tendo dificuldades com esse bug, que causa problemas nos servidores de CI e no desenvolvimento local.

Muito obrigado pelas reproduções e análises.
Tivemos um problema com um tar para ser baixado duas vezes e isso causou uma exceção
durante o untarring.

A equipe principal se concentrará na estabilidade durante toda a próxima semana antes
liberando 0,26

Em 28 de maio de 2017 às 22:44, andrsnn [email protected] escreveu:

Este parece ser um problema persistente. Sou capaz de reproduzir com:

[email protected]
[email protected]
[email protected]
[email protected]
amazon [email protected]
[email protected]
[email protected]

parece ter sucesso para o nó @> = 6.9.5

Pelo que eu posso dizer, o problema parece estar relacionado ao git repo
dependências devido a uma condição de corrida ao extrair o tar produzido a partir do git
arquivo.

Fiz um repo que exibe o comportamento.
https://github.com/andrsnn/yarn-git-dependency-issue

Até agora, rastreei o problema neste trecho de código localizado em
~ / .yarn / lib-legacy / util / git.js

_cloneViaLocalFetched (dest) {
var _this4 = this;

return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
  yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
    cwd: _this4.cwd,
    process: function process(proc, resolve, reject, done) {
      const extractor = tar.Extract({ path: dest });
      extractor.on('error', reject);
      extractor.on('end', done);

      proc.stdout.pipe(extractor);
    }
  });
})();

}

Ocasionalmente, o evento 'final' nunca é disparado do módulo node-tar. Isto
parece estar pendurado em uma emissão de 'dados', que contém um pedaço trucado do
arquivo yarn.lock da dependência git.

██████████████████████████████████████████████████ ██████████████████████████████████████████████████ ██████████████████████████████████████████████████ ██████████████████████████░ 176/177 {'0': 'dados',
'1': 0,4:
versão "4.0.6"
resolvido " https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb "

lodash.isstring@^4.0.1:
versão "4.0.1"
resolvido " https://registry.yarnpkg.com/lodash.isstring/-/lodash.isstring-4.0.1.tgz#d527dfb5456eca7cc9bb95d5daeaf88ba54a5451 "

lodash.keys@^3.0.0:
versão "3.1.2"
resolvido " https://registry.yarnpkg.com/lodash.keys/-/lodash.keys-3.1.2.tgz#4dbc0472b156be50a0b286855d1bd0b0c656098a "
dependências:
loda

Para determinar o que precede, envolvi o emissor de evento:

_cloneViaLocalFetched (dest) {
var _this4 = this;

return (0, (_asyncToGenerator2 || _load_asyncToGenerator()).default)(function* () {
  yield (_child || _load_child()).spawn('git', ['archive', _this4.hash], {
    cwd: _this4.cwd,
    process: function process(proc, resolve, reject, done) {
      const extractor = tar.Extract({ path: dest });

      var timeout;
      function log(args) {
        return function() {
          console.log(require('util').inspect(args));
          console.log(args[1].toString());
        };
      }
      function debug(emitter) {
          var originalEmitter = emitter.emit;

          emitter.emit = function() {
              console.log('eventName', arguments[0]);
              clearTimeout(timeout);
              timeout = setTimeout(log(arguments), 20000);
              originalEmitter.apply(emitter, arguments);
          };
      }

      debug(extractor);
      extractor.on('error', reject);
      extractor.on('end', done);


      proc.stdout.pipe(extractor);
    }
  });
})();

}

Isso pode muito bem ser um bug no node-tar ou uma dependência na qual ele depende.

Esperançosamente, outros podem lançar alguma luz sobre a correção. Tenho tido uma dificuldade
tempo com esse bug, causando problemas nos servidores de CI e no desenvolvimento local.

-
Você está recebendo isso porque modificou o estado abrir / fechar.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/764#issuecomment-304542314 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ACBdWLWEI3Aui9XTLxl7ISk-OaXSQLL0ks5r-eqlgaJpZM4KUM4j
.

Estava tendo esse problema na última semana desde a atualização do yarn, e o resolvi eventualmente alterando a versão do nó de 6.2.0 para 6.9.0 . Espero que isso ajude outras pessoas.

Mesmo problema. Ficou preso no último pacote enquanto "Buscava pacotes". Não acontecendo em todos os projetos, mas a maioria dos meus projetos teve esse problema. Eu reinstalei meu sistema ontem, então pode ser que a versão anterior não tivesse esses problemas ou o pacote que está bagunçando já estava em cache ou algo assim.

Versão do fio: v0.24.6
Versão do nó: experimentado v8.0.0, v7.10.0, v7.9.0, nada funcionou
OS: macOS 10.12.5

Yarn instalado via brew, node via nvm para tentar mais versões de node.

// EDITAR
ssh-agent solicitou a frase-senha e o yarn a engoliu. Quando eu pressiono Enter, pude ver a pergunta mais uma vez porque "Eu inseri a senha longa incorreta"

@vass-david com sua última edição, você ainda está tendo o problema?
@andrsnn - Tentei reproduzir o problema com seu repo usando várias combinações de Nó 4.8, Nó 6.10, Nó 7, Nó 8 e fio 0,24, 0,25, mestre. Não consegui reproduzir o problema. você pode confirmar que não está mais lá?

@ vass-david @JulianLeviston você pode usar strace no processo de fio preso para descobrir o que exatamente está preso? Aqui está um ótimo manual de como usá-lo.

@BYK não, pois agora entendi qual é o problema e que devo simplesmente inserir minha senha para ssh. Por outro lado, ele não deve engolir essa mensagem de prompt, então se o usuário não estiver ciente disso, ele pode nunca perceber o que aconteceu.
@kirs , você ainda precisa disso, mesmo que agora eu saiba qual é o problema?

A @kirs Mine está funcionando desde que atualizei o yarn.

Tive o mesmo problema. Excluir a pasta node_modules completamente e executar novamente yarn funcionou para mim!

eu tento

rm yarn.lock
yarn

funciona para mim

Tive o problema com node 7.10.0 e yarn v0.24.6 no docker, mas percebi que a pasta node_modules foi acidentalmente enviada. Remover a pasta node_modules e yarn clear cache resolveu o problema.

isso está acontecendo em grandes embalagens. pode ser bom se um aviso for dado em um determinado tamanho.

Eu tive o mesmo problema. Eu acredito que é um conflito de versão com o nó. Meu projeto estava usando a v81.2. Simplesmente mudei para a versão correta e o fio parou de pendurar:
nvm use v7.4

Ainda tenho esse problema na v1.9.4, mas igual a # 5055

Tive o mesmo problema:
OS: OSX 10.14.1 (Mojave)
Nó: 10.9.0
Fio: 1.12.3

Parece que provavelmente era um arquivo yarn.lock corrompido. Fazer o seguinte consertou:

yarn cache clean
rm yarn.lock
rm - r node_modules

yarn

O mesmo problema

OS: OSX 10.14.1 (Mojave)
Nó: 12.3.1
Fios: 1.16.0

Resolvi mudando para uma rede diferente (hotspot). Acho que o firewall da rede do nosso escritório tinha algumas restrições.

O mesmo problema

SO Windows 10

Minha solução: atualizar os drivers da placa-mãe

Tive o mesmo problema:
SO: Ubuntu 18.04
Nó: v8.10.0
Fio: 1.17.3

Eu resolvi isso fazendo o seguinte:
yarn cache clean

que novamente tentei o comando de instalação e funciona. embora demore alguns minutos para concluir o processo, seja paciente, pois ele funcionará. No meu caso demorou 10 minutos (depende da velocidade da internet) para completar o processo.

Atualizar o fio não ajudou. No meu caso, um dos pacotes era muito grande e não pôde ser baixado antes do tempo limite

A solução é instalar usando
yarn install --network-timeout 100000

ou adicione o arquivo .yarnrc ao seu projeto e coloque-o dentro de:
network-timeout 500000

mesmo aqui:

yarn install v1.22.4
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[###############################################################################################] 1908/1909

System:
    OS: macOS 10.15.3
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Memory: 192.86 MB / 8.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.13.1 - ~/.nvm/versions/node/v12.13.1/bin/node
    Yarn: 1.22.4 - ~/Documents/youpendo-app-bareworkflow/node_modules/.bin/yarn
    npm: 6.12.1 - ~/.nvm/versions/node/v12.13.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.2
      System Images: android-28 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.6 AI-192.7142.36.36.6392135
    Xcode: 11.3.1/11C504 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_232 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: ^4.8.0 => 4.9.0
    react: 16.11.0 => 16.11.0
    react-native: 0.62.2 => 0.62.2
  npmGlobalPackages:
    *react-native*: Not Found

Mesmo problema!
Por que este está fechado?

[email protected]
Node.js v12.18.2.

Executado para este repo:
https://github.com/metabase/metabase

Windows 10

Resumindo, verifique seu VPN. Ele está conectado?

Um colega de trabalho e eu estávamos depurando esse mesmo problema. Pararia apenas em um pacote específico, embora não tivéssemos certeza de qual pacote.

Basicamente, a pessoa reiniciou o computador mais cedo e, ao reiniciá-lo, também teve que configurar uma nova senha para a VPN. Portanto, sua VPN nunca se reconectou automaticamente. Como era um "problema com fio", não pensei muito sobre o vpn. Mas temos um repo da empresa com alguns pacotes e é onde ele estava pendurado. : /