Estou fazendo com que as dependências de vinculação demorem mais de 200 segundos com este https://github.com/macdja38/pvpsite/blob/master/package.json no Windows 10, em um SSD com um i7 decente.

Parece que o problema de desempenho pode ser causado pelo Windows Defender, desativando-o embora, possivelmente, desaconselhável, reduzindo 200s para algo próximo a 50.

Acho que deveria haver uma solução melhor do que reduzir a segurança.

Alguns outros usuários confirmaram que desabilitá-lo apenas no diretório raiz do seu projeto funciona, mas não posso confirmar, pois o Windows Defender se quebrou um pouco quando tentei fazer isso.

Eu tenho o mesmo problema com o git repo com cerca de 30 dependências.
Windows 10
nó v5.5.0
fio 0.16.1

Desativar o Windows Defender reduziu significativamente o tempo de vinculação

Provavelmente deveria ser "resolvido" por este PR ?

Sim, não há muito que possamos fazer aqui, infelizmente :( Os verificadores de vírus verificam todos os arquivos, e o ecossistema npm tem muitos arquivos pequenos. Arquivos pequenos geralmente têm um pouco mais de sobrecarga no NTFS em comparação com outros sistemas de arquivos, como EXT4 ou ZFS, mas é exacerbado por antivírus.

Dito isto, o Yarn deve _ainda_ ser mais rápido que o npm, mas não será tão rápido como no Linux ou Mac.

Estou em um Mac sem ter nenhum antivírus instalado. Mas ainda vejo o mesmo problema, vincular uma quantidade considerável de tempo, mesmo com um aplicativo angular-js simples.

eu tenho esse problema também. Demorou 174s no Ubuntu.

Comecei a ter esse problema somente depois de fazer upgrade de 0.17.8 para 0.17.19 . Mac sem antivírus.

O estranho também é que preciso lançar o processo de vinculação sempre que excluir um pacote. O Npm faz isso mais rápido. E a vinculação realmente leva muito tempo.

Isso pode ser reproduzido com este package.json (no Heroku):

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

Com o yarn 0.17.8, a instalação leva 37s. Com o yarn 0.17.10, a instalação leva 97 segundos. Nenhuma outra mudança (novos aplicativos Heroku a cada vez).

✨ Feito em 45.10s.

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

Por favor, alguém pode explicar o que yarn faz exatamente na etapa "Vinculando dependências"?
Porque o número máximo nesta etapa varia de ~ 1000 a ~ 65000 para o mesmo projeto em máquinas diferentes. O que este número significa?

Tendo esse problema também. Adicionar uma dependência com yarn add parece acionar "Vinculando dependências" e leva uma eternidade. Tive que voltar para o npm por enquanto.

nó: 6.9.2
SO: Windows 10

nó: 7.3.0
SO: Windows 10 64
O mesmo para mim

O mesmo aqui. Links 23420 ... algo, e leva cerca de um minuto e meio em um dia bom.

Fio 0.19.1
NodeJS 7.3.0
Windows 10

yarn add moment leva 105 segundos. Não tem dependências. : /

EDIT: Desligar o Windows Defender reduz o tempo de aproximadamente 30 a aproximadamente 50 segundos. Tentei excluir o diretório em que estou trabalhando, mas isso não pareceu ajudar.

Apenas executei uma nova cópia do create-react-app e demorou 876,37s. Eu entendo que você não tem muito / nenhum controle sobre como o antivírus funciona, mas minha experiência com NPM e CRA foi muito mais rápida no Windows.

No Windows 10, use apenas o shell bash do Ubuntu como um conselho geral.

No Windows 10, use apenas o shell bash do Ubuntu como um conselho geral.

E / S de disco é extremamente lento no subsistema do Windows para Linux, é uma limitação conhecida no momento

mas minha experiência com NPM e CRA foi muito mais rápida no Windows.

@JeffBaumgardt - Interessante ... Yarn é mais lento no Windows, mas ainda deve ser mais rápido que npm!

@ Daniel15 provavelmente deveria ser, mas não é. As instalações e desinstalações de nós eram menores para mim. Então, eu faria npm add <packages> --save-dev , excluiria yarn.lock e executaria yarn e isso seria mais rápido do que executar yarn add <packages> -D uma única vez. Agora que todo mundo está no fio, é claro que não quero excluir o bloqueio e forçar todos a atualizarem seus pacotes. Em vez disso, o seguinte tem sido ótimo:

cc @echobnet

Para qualquer pessoa no windows 10 + windows defender

1. Configurações do primeiro clique

   

2. Role para baixo até exclusões

   

3. Execute yarn cache dir para obter a localização da sua pasta de cache

   • Adicione esta pasta de cache à lista de exclusão
   • Adicione a pasta node_modules do seu projeto à lista de exclusão

4. Aceleração para um projeto de reação x 3-10

@SleeplessByte ou você pode simplesmente adicionar yarn e node aos processos excluídos.

Não é apenas um problema no Windows. Tenho visto tempos de link horríveis no meu Mac Pro.

OS: OS X 10.11.6 (El Capitan)
Nó: 7.6.0
Fio: 0,20.3

Posso confirmar que também é _muito_ lento no Mac 10.12.3. Não relacionado a janelas.

E parece que minha configuração está _muito_ mais lenta do que outras neste tópico. O yarn às vezes tenta vincular cerca de 600.000 arquivos em pequenos projetos. Isso pode levar mais de 30 minutos. Atualmente, eu tento com um cache limpo e todas as noites (v0.22.0-20170226.1626). Eu uso o registro oficial, bem como um registro privado personalizado para certos pacotes com escopo definido. No entanto, meus colegas não sofrem com esse problema, então não acho que o registro privado personalizado seja o problema (e a obtenção de pacotes já está concluída de qualquer maneira). Também temos alguns arquivos relativos com o protocolo path: em nosso package.json .

Tenho muitos problemas ao instalar https://github.com/google/material-design-icons que tem _uma grande quantidade de pequenos arquivos_ que parecem ser problemáticos para outras pessoas também (https://github.com/google/ material-design-icons / issues / 518). Não sei se meu hardware está quebrado ao lidar com muitos arquivos pequenos ou algo parecido ou se isso tem alguma relação. Mais uma vez, meus colegas não têm tantos problemas para instalar https://github.com/google/material-design-icons quanto eu.

Atualizar

Não tenho certeza ... parece_como instalar um pacote com file: coloca um módulo no cache contendo node_modules/ e outras coisas. Isso é _realmente_ um problema se você tiver vários exemplos, todos contendo seus próprios node_modules/ . Parece que .npmignore , etc. é ignorado nas instalações de file: . Isso provavelmente se resume a https://github.com/yarnpkg/yarn/issues/2165 , se a solução for _não_ armazenar em cache os arquivos resolvidos localmente. Se eu abrir meu cache ( $ yarn cache dir ) e procurar por módulos onde instalar com file: e eles contêm um diretório node_modules ou outros diretórios grandes, posso acelerar o linking phase removendo esses diretórios manualmente. Agora tudo parece instalar com boa velocidade.

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

Tive que esperar esse período de tempo adicionando qualquer novo pacote com yarn add ...
Win7 / w Yarn v0.21.3
Tenho um pacote de material-design-icons em meu aplicativo.
Acho que este está relacionado https://github.com/yarnpkg/yarn/issues/990

@kuncevich tudo funciona bem do meu lado, durante o tempo de execução do yarn add start task manager ctrl + alt + esc verifique qual programa usa a cpu mais alta, no meu caso era antivírus, então tive que excluir não apenas os diretórios% appdata%, mas também o diretório do projeto e as coisas ficaram rápidas novamente

@kuncevic você pode ser afetado pelo bug que encontrei no windows: https://github.com/yarnpkg/yarn/pull/2958

Essencialmente, o yarn sempre pode copiar todos os arquivos em node_modules para cada operação.

@asolopovas no meu caso é node.exe como 10-26 % :

Meu AV não é um problema, mesmo se eu o desliguei completamente, não consigo ver nenhuma melhora na velocidade do fio.

nó -v 6.9.2

@kuncevic atualize seu nó para 7 e verifique se isso torna as coisas mais rápidas, caso contrário, @vbfox está apontando na direção certa.

Essencialmente, o yarn sempre pode copiar todos os arquivos em node_modules para todas as operações.

@vbfox você poderia explicar o porquê? Estou olhando para a saída detalhada do yarn e descobrindo que quase todo o tempo é gasto criando diretórios e copiando arquivos, como parece fazer cada um individualmente, em vez de, digamos, criar um diretório para cada _pacote_ e, em seguida, copiar o pacote inteiro, que deve ser um pouco mais rápido, ou mesmo apenas vincular simbolicamente todos os pacotes, o que pode ser mais rápido novamente. Não é seguro fazer isso?

@danpalmer, a fase de vinculação funciona essencialmente em três grandes etapas:

1. Encontre todos os arquivos que precisam estar em node_modules
2. Compare esta lista com o que já está lá e encontre o que precisa ser copiado do cache para node_modules
3. Faça a cópia

Devido a um bug libuv / nodejs ( utime é usado pelo yarn e o bug é que ele define os milissegundos como zero) os arquivos copiados pelo yarn em uma execução anterior são sempre considerados diferentes (a versão no cache tem um tempo modificado normal, mas todos os arquivos em node_modules têm uma versão zero-para-milissegundos), portanto, a fase 2 sempre relata que tudo mudou.

Como o bug foi corrigido no nó 7.1, é muito fácil de corrigir se você não estiver limitado a LTS (a primeira operação do yarn em um repo será lenta, pois os arquivos foram criados com o bugado utime mas todos os seguintes serão muito mais rápido). Meu PR basicamente corrige isso, ignorando a parte dos milissegundos dos tempos de arquivo do Windows ao compará-los.

Em relação à cópia do pacote inteiro, não é uma operação que existe nos sistemas de arquivos atuais AFAIK, todos funcionam no nível do arquivo.
O melhor windows fornece é uma API FileCopy (eu tenho um PR para usá-lo no yarn: https://github.com/yarnpkg/yarn/pull/2960), mas é apenas um pouco mais rápido do que usar a API de fluxo nodejs nativa.

Quanto ao symlinking, não sei por que não é feito, não tenho conhecimento suficiente sobre gerenciadores de pacotes javascript (algumas modificações são feitas nos arquivos do pacote, como remover pastas de teste, mas symlinking de arquivos individuais não faria isso diferente) mas como também não é o caso no linux / macos (onde é muito mais comum do que no Windows), pode haver uma boa razão.

Minha experiência de atualização para Node 7.8.0 : https://github.com/yarnpkg/yarn/issues/990#issuecomment -290288375

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

Considerando que na maioria das vezes as pessoas estão reconectando faixas de bibliotecas ao alternar entre ramos - talvez haja uma maneira melhor de fazer isso?

Você poderia criar um ID exclusivo para cada compilação de node_modules e, em seguida, criar um link simbólico para todo o diretório de um cache? Desta forma, alternar ramos para frente e para trás é, na verdade, apenas criar um link simbólico diferente node_modules

Concedido, você estará gravando muito no disco, já que agora está armazenando em cache todas as versões de node_modules que encontrar, mas poderia haver otimizações para criar links simbólicos para diretórios, de modo que você realmente só armazenando uma árvore de links simbólicos?

Perdoe-me por ser ingênuo, não sou o mais educado quando se trata de sistemas de arquivos unix e menos ainda do Windows, mas ficaria feliz em me aprofundar nisso, como um exercício educacional, e tentar fornecer um prova de conceito dessa ideia se ela não for obviamente falha de alguma forma.

O pnpm e o ied empregam algumas das técnicas que você mencionou, mas não tenho certeza absoluta , tentei há algum tempo, mas causaram problemas no Windows ou não eram rápidos como o fio.

Eu também tive muito tempo para criar-reagir-app com yarn
servidor windows 2012
nó 7.9.0
fio 0,22
Feito em 554.08s.

Mas em outros casos, é muito mais rápido se nenhuma instalação React incluída

Eu não observei muito tempo de vinculação recentemente. Corrida
Fios - v0.23.2
nó - 6.10.2 ou 7.9.10 (usando nvm para alternar)

Tentei isso em um Mac e Archlinux (Manjaro)

Posso confirmar que adicionar node e yarn às exclusões do Windows Defender reduziu o tempo de vinculação em cerca de 60% em minha máquina Windows.

+1

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

Mudar para o nó 7.9.0 não acelerou para mim. Adicionar 'yarn', 'node' e 'npm' ao Windows Defender (com e sem extensões .exe, não tenho certeza do que é necessário) acelerou 3x para mim, mas ainda 50% mais do que a instalação npm.

Além disso, remover toda a proteção de qualquer coisa em execução no nó ou qualquer pacote sendo instalado não parece uma boa idéia para mim ...

Adicionando minha experiência - adicionar node.exe / yarn.exe à lista de exceções do Windows Defender cortou nosso tempo de instalação do yarn pela metade (de 60 para 30).

Também estou vendo isso, o que torna frustrante iterar rapidamente durante o desenvolvimento de um pacote porque leva muito tempo para atualizar um único pacote.

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

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

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

:(

Adicionando meu +1 no MacBook Pro de meados do verão de 2010 (Sierra 10.12.4) usando yarn 0.24.5, node 7.10.0 e npm 4.2.0:

λ yarn add bootstrap-sass
fio add v0.24.5
[1/4] 🔍 Resolvendo pacotes ...
[2/4] 🚚 Buscando pacotes ...
[3/4] 🔗 Vinculando dependências ...
[4/4] 📃 Construindo novos pacotes ...
arquivo de bloqueio salvo com sucesso.
sucesso Salvou 1 nova dependência.
└─ [email protected]
✨ Feito em 123.52s.

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

Voltar para o npm install consertou isso para mim .. Eu estava recebendo - u'stream ': u' [3/4] Vinculando dependências no yarn e nenhum erro no NPM ..

Algo deu errado com a última compilação, talvez

Executando isso por meio do Docker.

@iwarner npm 5.0 é uma boa escolha.

Eu corro o yarn no Vagrant (Ubuntu Xenial) e no Jenkins. Existem dois subprojetos com package.json.
npm -v 3.10.10
node -v 6.10.1
yarn install v0.21.3

Trocamos do npm para o yarn há algum tempo, porque tivemos um problema de tempo limite (4 horas não eram suficientes) para a instalação do npm.

Agora o fio funciona cerca de 30% do tempo, mas 70% do tempo obtemos um tempo limite de 4 horas em algum ponto. Pode ser a primeira instalação do yarn, ou a segunda, ou podemos atingir o tempo limite durante a execução de testes de unidade (jest).

Esta é uma duplicata de https://github.com/yarnpkg/yarn/issues/990 , há um gráfico de comparação e parece que as versões mais recentes do Yarn tiveram um bom progresso.
Se ainda for um problema, registre um novo problema com as etapas de reprodução e uma comparação com o npm mais recente

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5, 8 GB de RAM

:(

Windows 10 v 1709 + SSD + PowerShell + Nó 6.12.2:
A instalação do Yarn era rápida até o último pacote, parecia travar em um comando de pré-instalação.
Segui as instruções aqui para adicionar exclusões para o Windows Defender, mas também fiz minha fonte checar a fonte% USERPROFILE%, o que o tornou drasticamente lento. Verificado em c: foi muito mais rápido.

Alguma solução para a plataforma Ubuntu? Eu literalmente tenho que pensar duas vezes antes de adicionar um pacote.

Ubuntu é super rápido para mim, sem lentidão em tudo.

Na sexta-feira, 23 de fevereiro de 2018, 11h13, Basant Besra, [email protected] escreveu:

Alguma solução para a plataforma Ubuntu? Eu literalmente tenho que pensar duas vezes antes
adicionar um pacote.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
.

Isso é super irritante. Eu literalmente mudei uma linha em um módulo, republiquei com uma nova versão e yarn add module levou mais de 5 minutos.

Seria mais rápido atualizar manualmente meus pacotes usando um editor de texto

Eu também tenho esse problema:

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

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

NodeJS: v9.9.0
Fios: v1.5.1

Também muito lento para mim Done in 254.32s.

nó v8.10.0
npm 5.6.0

OSX 10.11.6 (15G19009)

Voltei para [email protected] e as coisas estão funcionando muito bem.

Estamos usando o recurso de cache offline para evitar esse problema na maioria das vezes, mas assim que o package.json ou o yarn-lockfile mudar, estaremos de volta ao problema. A vinculação leva 10 minutos em nossa máquina Linux. Não acho que isso seja específico do Windows.

Definitivamente, este não é um problema apenas do Windows (o que deve ficar evidente em todas as postagens de pessoas em máquinas não-Windows)!

Estou no macOS High Sierra 10.13.4, usando o nó 10.1.0 (npm 5.6.0) e o yarn 1.6.0. Usando o yarn, instalar uma dependência demorou cerca de 40s. Mudei para npm e demorou cerca de 10 segundos. Vou ficar com o npm por enquanto.

O mesmo para a nossa caixa de 7 centos. Alguma atualização sobre isso?
fio: v1.7.0
npm: v5.7.1

está acontecendo comigo no 1.9.2 no mac no nó 10

Para mim no macOS HighSierra, o Avast FileShield estava causando o problema. Eu adicionei o executável do yarn como caminho excluído, usando which yarn . Parece ok agora, darei uma atualização se ele retornar.

está acontecendo comigo no 1.9.2 no mac no nó 10

O mesmo aqui. Yarn 1.9.2, nó 10.6.0 em High Sierra.

@bestander este não é um problema do Windows. Posso reproduzir no meu Mac com o Yarn 1.9.4. Este problema deve ser reaberto.

@davidgoli , melhor abrir um novo problema, este é um novo e deve ser triado separadamente

O Yarn é bastante lento para qualquer ambiente em que o executei. Debian, Mac, Windows. O novo problema foi aberto? ou a RFC que se livrar de node_modules vai resolver isso?

tenho o mesmo problema, já mudei para npm, mas ainda tenho bug

Eu também tenho o mesmo problema com o Yarn. Alguma solução encontrada?

Esta é uma duplicata do # 990, há um gráfico de comparação e parece que as versões mais recentes do Yarn fizeram um bom progresso.
Se ainda for um problema, registre um novo problema com as etapas de reprodução e uma comparação com o npm mais recente

Isso não é uma duplicata, esse problema não é apenas sobre o Windows. Abrir um novo problema causaria uma perda de contexto.

Eu tenho o mesmo problema!

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

Done in 179.59s.

MacOS / Docker

Vagabundo 2.2.4
Convidado: Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
Anfitrião: MacOS 10.14.5 Mojave

fio 1.16.0
npm 6.9.0

MacBook Pro (Retina, 13 polegadas, início de 2015)
Processador Intel Core i5 de 2,7 GHz
Memória 16 GB 1867 MHz DDR3

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

Na verdade, não consigo executar yarn install sem perder mais de 25 minutos de produtividade. É um absurdo. Não acredito que seja um problema do Windows. Parece-me muito provável que haja algum problema ao executar em um ambiente virtualizado. Talvez a ver com pastas sincronizadas / verificação do estado do arquivo no sistema operacional convidado?

fio v1.17.3
nó v10.16.3
npm 6.9.0

janelas

Tentei colocar o local da pasta do meu projeto de aplicativo na mesma seção do disco que yarn cache dir .
Yarn cache dir -> C: UsuáriosAppDataLocalYarnCachev4

O resultado:
local antigo -> D: myApp Done in 747.17s.
novo local -> C: myApp Done in 488.97s.

C e D são o mesmo disco físico.

Mac

No entanto, o Mac é mais rápido que o Windows Done in 121.37s

Acho que o gargalo é a velocidade de leitura / gravação do disco?

OS X 10.15
fio v1.22.4
nó v12.13.0
npm v6.12.0

Eu ainda estou experimentando isso. O projeto está localizado em uma imagem de disco criptografada montada. A instalação de um único pacote leva vários minutos com um package.json relativamente pequeno. Não fiz o benchmarking, mas o npm parece muito mais rápido.

Edit: Acontece que alterar a pasta de cache padrão do yarn para estar no mesmo volume criptografado corrigiu isso para mim.

Também fui atingido por isso e estou correndo:

SO: Ubuntu 18.04.2
Fios: 1.22.4
Nó: 14.7.0
NPM: 6.14.7