Je dois relier des dépendances à plus de 200 secondes avec ce https://github.com/macdja38/pvpsite/blob/master/package.json sur Windows 10, sur un SSD avec un i7 décent.

Il semble que le problème de performances puisse être causé par Windows Defender, le désactivant alors qu'il est peut-être déconseillé de réduire les 200 à un niveau plus proche de 50.

Je pense qu'il devrait y avoir une meilleure solution que de réduire la sécurité.

Certains autres utilisateurs ont confirmé que le désactiver uniquement dans le répertoire racine de votre projet fonctionne, mais je ne peux pas le confirmer car Windows Defender s'est un peu cassé lorsque j'ai essayé de le faire.

J'ai le même problème avec git repo avec environ 30 dépendances.
Windows 10
nœud v5.5.0
fil 0.16.1

La désactivation de Windows Defender a considérablement réduit le temps de liaison

Devrait probablement être «résolu» par ce PR ?

Oui, nous ne pouvons malheureusement pas faire grand chose ici: (Les antivirus analysent tous les fichiers, et l'écosystème npm contient beaucoup de petits fichiers. Les petits fichiers ont généralement un peu plus de surcharge sur NTFS par rapport à d'autres systèmes de fichiers tels que EXT4 ou ZFS, mais il est exacerbé par les scanners de virus.

Cela dit, Yarn devrait encore être plus rapide que npm, ce ne sera tout simplement pas aussi rapide que sur Linux ou Mac.

Je suis sur un Mac sans avoir installé de scanners antivirus. Mais je vois toujours le même problème, la liaison prenant beaucoup de temps, même avec une simple application angular-js.

J'ai ce problème aussi. Il a fallu 174 secondes sur Ubuntu.

J'ai commencé à avoir ce problème seulement après être passé de 0.17.8 à 0.17.19 . Mac sans antivirus.

Une chose étrange aussi est que je dois lancer un processus de liaison à chaque fois que je supprime un paquet. Npm le fait plus rapidement. Et la liaison prend vraiment beaucoup de temps.

Cela peut être reproduit avec ce package.json (sur 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"
  }
}

Avec le fil 0.17.8, l'installation prend 37s. Avec le fil 0.17.10, l'installation prend 97 secondes. Aucun autre changement (nouvelles applications Heroku à chaque fois).

✨ Fait en 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"

S'il vous plaît, quelqu'un peut-il expliquer exactement ce que fait le fil à l'étape "Lier les dépendances"?
Parce que le nombre maximum à cette étape varie de ~ 1000 à ~ 65000 pour le même projet sur différentes machines. Que signifie ce nombre?

Avoir ce problème aussi. Ajouter une dépendance avec yarn add semble déclencher "Lier les dépendances" et cela prend une éternité. J'ai dû revenir à npm pour le moment.

nœud: 6.9.2
Système d'exploitation: Windows 10

nœud: 7.3.0
Système d'exploitation: Windows 10 64
Pareil pour moi

Pareil ici. Liens 23420 ... quelque chose, et prend environ une minute et demie lors d'une bonne journée.

Fil 0.19.1
NodeJS 7.3.0
Windows 10

yarn add moment prend 105 secondes. Il n'a pas de dépendances. : /

MODIFIER: la désactivation de Windows Defender réduit le temps à ~ 30 à ~ 50 secondes. J'ai essayé d'exclure le répertoire dans lequel je travaille, mais cela n'a pas semblé aider.

Je viens de lancer une nouvelle copie de create-react-app et cela a pris 876,37 s. Je comprends que vous n'avez pas beaucoup / aucun contrôle sur le fonctionnement de l'antivirus, mais mon expérience avec NPM et CRA a été beaucoup plus rapide sous Windows.

Sur Windows 10, utilisez simplement le shell bash Ubuntu comme conseil général.

Sur Windows 10, utilisez simplement le shell bash Ubuntu comme conseil général.

Les E / S disque sont extrêmement lentes dans le sous-système Windows pour Linux, c'est une limitation connue pour le moment

mais mon expérience avec NPM et CRA a été beaucoup plus rapide sous Windows.

@JeffBaumgardt - Intéressant ... Le fil est plus lent sous Windows, mais il devrait quand même être plus rapide que npm!

@ Daniel15 ça devrait probablement l'être, mais ce n'est pas le cas. Les installations et désinstallations de nœuds étaient plus petites pour moi. Je ferais donc npm add <packages> --save-dev , supprimais yarn.lock et exécutais yarn et cela serait plus rapide que de lancer yarn add <packages> -D une seule fois. Maintenant que tout le monde est sur le fil, bien sûr, je ne veux pas supprimer le verrou et forcer tout le monde à mettre à niveau leur bundle. Au lieu de cela, ce qui suit a été formidable:

cc @echobnet

Pour tous les utilisateurs de Windows 10 + Windows Defender

1. Paramètres du premier clic

   

2. Faites défiler les exclusions

   

3. Exécutez yarn cache dir pour obtenir l'emplacement de votre dossier de cache

   • Ajouter ce dossier de cache à la liste d'exclusion
   • Ajoutez le dossier node_modules de votre projet à la liste d'exclusion

4. Accélération pour un projet React x 3-10

@SleeplessByte ou vous pouvez simplement ajouter yarn et node aux processus exclus.

Pas seulement un problème sur Windows. J'ai vu des temps de liaison horribles sur mon Mac Pro.

Système d'exploitation: OS X 10.11.6 (El Capitan)
Nœud: 7.6.0
Fil: 0.20.3

Je peux confirmer qu'il est également très lent sur Mac 10.12.3. Non lié aux fenêtres.

Et il semble que ma configuration soit plus lente que les autres de ce fil. yarn essaie parfois de lier environ 600 000 fichiers dans de petits projets. Cela peut prendre plus de 30 minutes. Je l'essaie actuellement avec un cache propre et tous les soirs (v0.22.0-20170226.1626). J'utilise le registre officiel ainsi qu'un registre privé personnalisé pour certains packages étendus. Cependant, mes collègues ne souffrent pas de ce problème, donc je ne pense pas que le registre privé personnalisé soit le problème (et la récupération des packages est déjà terminée de toute façon). Nous avons également des fichiers relatifs avec le protocole path: dans notre package.json .

J'ai beaucoup de problèmes pour installer https://github.com/google/material-design-icons qui contient _de nombreux petits fichiers_ qui semblent également gênants pour d'autres personnes (https://github.com/google/ material-design-icons / issues / 518). Je ne sais pas si mon matériel est cassé en manipulant beaucoup de petits fichiers ou quelque chose comme ça ou si cela est lié du tout. Encore une fois, mes collègues n'ont pas autant de problèmes à installer https://github.com/google/material-design-icons que moi.

Mettre à jour

Je ne suis pas sûr ... cela ressemble à l'installation d'un paquet avec file: met un module dans le cache contenant node_modules/ et d'autres choses. C'est _ vraiment_ un problème si vous avez plusieurs exemples contenant tous leur propre node_modules/ . Il semble que .npmignore , etc. soit ignoré pour les installations file: . Cela revient probablement à https://github.com/yarnpkg/yarn/issues/2165 , si la solution est de _pas_ mettre en cache les fichiers résolus localement du tout. Si j'ouvre mon cache ( $ yarn cache dir ) et cherche des modules pourquoi installer avec file: et qu'ils contiennent un répertoire node_modules ou d'autres gros répertoires, je peux accélérer le linking phase en supprimant ces répertoires manuellement. Maintenant, tout semble s'installer avec une bonne vitesse.

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

J'ai dû attendre ce laps de temps pour ajouter un nouveau package avec yarn add ...
Win7 / w Yarn v0.21.3
J'ai reçu le package material-design-icons dans mon application.
Je pense que celui-ci est lié https://github.com/yarnpkg/yarn/issues/990

@kuncevich tout fonctionne bien de mon côté, pendant l'exécution de votre fil ajouter le gestionnaire de tâches de démarrage ctrl + alt + esc vérifier quel programme utilise le processeur le plus élevé, dans mon cas, c'était un antivirus, donc j'ai dû exclure non seulement les répertoires% appdata% mais aussi le répertoire du projet et les choses sont redevenues rapides

@kuncevic vous pourriez être affecté par le bogue que j'ai trouvé sur Windows: https://github.com/yarnpkg/yarn/pull/2958

Essentiellement, yarn peut toujours copier chaque fichier dans node_modules pour chaque opération.

@asolopovas dans mon cas c'est node.exe comme 10-26 % :

Mon AV n'est pas un problème, même si je viens de l'éteindre complètement, je ne vois aucune amélioration de la vitesse du fil.

nœud -v 6.9.2

@kuncevic met à jour votre nœud à 7 et vérifie si cela accélère les choses, sinon

Essentiellement, yarn peut toujours copier chaque fichier dans node_modules pour chaque opération.

@vbfox pourriez-vous expliquer pourquoi? Je regarde la sortie verbeuse de yarn et constate que presque tout le temps est passé à créer des répertoires et à copier des fichiers, car il semble faire chacun individuellement, plutôt que, par exemple, de créer un répertoire pour chaque _package_ puis de copier le tout le paquet, ce qui devrait être un peu plus rapide, ou même simplement un lien symbolique de tous les paquets qui pourraient être à nouveau plus rapides. Ne sont-ils pas sûrs de le faire?

@danpalmer la phase de liaison fonctionne essentiellement en 3 grandes étapes:

1. Trouvez tous les fichiers qui doivent être en node_modules
2. Vérifiez cette liste par rapport à ce qui existe déjà et trouvez ce qui doit être copié du cache vers node_modules
3. Faire la copie

En raison d'un bogue libuv / nodejs ( utime est utilisé par yarn et le bogue est qu'il met les millisecondes à zéro), les fichiers copiés par yarn lors d'une exécution précédente sont toujours différents (la version en cache a un heure normale de modification mais tous les fichiers dans node_modules ont une version zéro pour millisecondes) donc la phase 2 signale toujours que tout a changé.

Comme le bogue est corrigé dans le nœud 7.1, il est assez facile à corriger si vous n'êtes pas limité à LTS (la première opération de fil sur un repo sera lente car les fichiers ont été créés avec le buggy utime mais tout ce qui suit sera beaucoup plus rapide). Mon PR corrige essentiellement cela en ignorant la partie des millisecondes des temps de fichier sur Windows lors de leur comparaison.

En ce qui concerne la copie du paquet entier, ce n'est pas une opération qui existe sur les systèmes de fichiers actuels AFAIK, ils fonctionnent tous au niveau du fichier.
Le meilleur que Windows fournit est une API FileCopy (j'ai un PR pour l'utiliser dans yarn: https://github.com/yarnpkg/yarn/pull/2960) mais c'est juste un peu plus rapide que d'utiliser l'API native de stream nodejs.

En ce qui concerne la liaison symbolique, je ne sais pas pourquoi cela n'est pas fait, je ne connais pas suffisamment les gestionnaires de packages javascript (quelques modifications sont apportées aux fichiers de package, comme la suppression des dossiers de test, mais la liaison symbolique de fichiers individuels ne rendrait pas cela différent) mais comme ce n'est pas non plus le cas sous linux / macos (où c'est beaucoup plus courant que sous Windows), il peut y avoir une bonne raison.

Mon expérience de mise à niveau vers 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

Étant donné que la plupart du temps, les gens relient des pans de bibliothèques lorsqu'ils passent d'une succursale à l'autre - peut-être y a-t-il une meilleure façon de procéder?

Pourriez-vous créer un identifiant unique pour chaque build de node_modules , puis créer un lien symbolique le répertoire entier à partir d'un cache? De cette façon, changer de branche d'avant en arrière est en réalité une simple liaison symbolique de différents node_modules

Certes, vous allez écrire beaucoup sur le disque puisque maintenant vous mettez en cache toutes les versions de node_modules vous rencontrez, mais pourrait-il y avoir des optimisations pour créer des liens symboliques vers des répertoires afin que vous ne soyez vraiment que stocker un arbre de liens symboliques?

Pardonnez-moi d'être naïf, je ne suis pas le plus éduqué en ce qui concerne les systèmes de fichiers Unix et encore moins Windows, mais je serais heureux de creuser là-dedans, comme exercice éducatif, et d'essayer de fournir un preuve de concept de cette idée si elle n'est manifestement pas défectueuse.

PNPM et ied emploient certaines des techniques que vous évoquez , je pense, pas tout à fait sûr, les essayé il y a quelque temps , mais ils ont soit causé des problèmes sous Windows ou ne sont pas rapidement fil.

Moi aussi j'ai eu très longtemps pour créer-réagir-app avec du fil
serveur windows 2012
nœud 7.9.0
fil 0.22
Fait en 554.08s.

Mais dans d'autres cas, c'est beaucoup plus rapide si aucune installation React n'est incluse

Je n'observe pas de temps de liaison depuis longtemps. Fonctionnement
Fil - v0.23.2
node - 6.10.2 ou 7.9.10 (en utilisant nvm pour basculer)

J'ai essayé cela sur un mac et archlinux (Manjaro)

Je peux confirmer que l'ajout de nœuds et de fils aux exclusions de Windows Defender a réduit le temps de liaison d'environ 60% sur ma machine Windows.

+1

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

Le passage au nœud 7.9.0 ne l'a pas accéléré pour moi. L'ajout de 'yarn', 'node' et 'npm' à Windows Defender (avec et sans extensions .exe, je ne sais pas ce qui est nécessaire) l'a accéléré 3x pour moi, mais toujours 50% plus long que l'installation de npm.

De plus, supprimer toute protection de tout ce qui s'exécute dans le nœud ou de tout paquet en cours d'installation ne me semble pas une bonne idée ...

Ajout de mon expérience - l'ajout de node.exe / yarn.exe à la liste d'exceptions de Windows Defender a réduit de moitié le temps d'installation de notre fil (de 60 à 30).

Je vois cela aussi, il est frustrant d'itérer rapidement tout en développant un package car il faut tellement de temps pour mettre à jour un seul package.

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

:(

Ajout de mon +1 sur MacBook Pro mi-été 2010 (Sierra 10.12.4) en utilisant le fil 0.24.5, le nœud 7.10.0 et npm 4.2.0:

λ yarn add bootstrap-sass
fil ajouter v0.24.5
[1/4] 🔍 Résolution des packages ...
[2/4] 🚚 Récupération des packages ...
[3/4] 🔗 Lier les dépendances ...
[4/4] 📃 Construction de nouveaux packages ...
succès Fichier de verrouillage enregistré.
succès Sauvé 1 nouvelle dépendance.
└─ [email protected]
✨ Fait en 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"
}

Revenir à npm install l'a corrigé pour moi. J'obtenais - u'stream ': u' [3/4] Lier les dépendances dans yarn et aucune erreur dans NPM ..

Quelque chose ne va pas avec la dernière version peut-être

Exécuter cela via Docker.

@iwarner npm 5.0 est un bon choix.

Je lance du fil dans Vagrant (Ubuntu Xenial) et par Jenkins. Il existe deux sous-projets avec package.json.
npm -v 3.10.10
nœud -v 6.10.1
fil installer v0.21.3

Nous sommes passés de npm à yarn il y a quelque temps, car nous avions un problème de timeout (4 heures ne suffisaient pas) pour l'installation de npm.

Maintenant, le fil fonctionne environ 30% du temps, mais pendant 70% du temps, nous obtenons un délai de 4h à un moment donné. Il peut s'agir de la première installation de fil, ou de la seconde, ou nous pouvons expirer lors de l'exécution de tests unitaires (plaisanterie).

Ceci est un double de https://github.com/yarnpkg/yarn/issues/990 , il existe un tableau de comparaison et il semble que les dernières versions de Yarn aient fait de bons progrès.
Si le problème persiste, veuillez déposer un nouveau problème avec les étapes de repro et une comparaison avec le dernier npm

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5, 8 Go de RAM

:(

Windows 10 v 1709 + SSD + PowerShell + Node 6.12.2:
L'installation de Yarn était rapide jusqu'au dernier package, semblait rester bloqué sur une commande de pré-installation.
J'ai suivi les instructions ici pour ajouter des exclusions pour Windows Defender, mais j'ai également fait vérifier ma source sur la source% USERPROFILE%, ce qui l'a considérablement ralentie. Vérifié en c: c'était beaucoup plus rapide.

Une solution pour la plateforme Ubuntu? Je dois littéralement réfléchir à deux fois avant d'ajouter un package.

Ubuntu est super rapide pour moi, pas de lenteur du tout.

Le vendredi 23 février 2018, 11:13 Basant Besra, [email protected] a écrit:

Une solution pour la plateforme Ubuntu? Je dois littéralement réfléchir à deux fois avant
ajouter un package.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
.

C'est super ennuyeux. J'ai littéralement changé une ligne dans un module, je l'ai republiée sous une nouvelle version et yarn add module pris plus de 5 minutes.

Ce serait plus rapide de mettre à jour manuellement mes packages à l'aide d'un éditeur de texte

Je rencontre également ce problème:

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.

Mon système est 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
Fil: v1.5.1

Aussi super lent pour moi Done in 254.32s.

nœud v8.10.0
npm 5.6.0

OSX 10.11.6 (15G19009)

Je suis revenu à [email protected] et les choses fonctionnent très bien.

Nous utilisons la fonctionnalité de cache hors ligne pour éviter ce problème la plupart du temps, mais dès que le package.json ou yarn-lockfile change, nous revenons à ce problème. La liaison prend 10 minutes sur notre machine Linux. Je ne pense pas que ce soit spécifique à Windows.

Ce n'est certainement pas un problème uniquement Windows (ce qui devrait être évident à partir de tous les messages de personnes sur des machines non Windows)!

Je suis sous macOS High Sierra 10.13.4, en utilisant le nœud 10.1.0 (npm 5.6.0) et le fil 1.6.0. En utilisant du fil, l'installation d'une dépendance a pris environ 40 secondes. Je suis passé à npm et cela a pris environ 10 secondes. Je m'en tiendrai à npm pour le moment.

Idem pour notre boîte centos 7. Des mises à jour à ce sujet?
fil: v1.7.0
npm: v5.7.1

cela m'arrive sur 1.9.2 sur mac sur le nœud 10

Pour moi, sur macOS HighSierra, Avast FileShield était à l'origine du problème. J'ai ajouté l'exécutable yarn comme chemin exclu, en utilisant which yarn . Cela semble ok maintenant, je donnerai une mise à jour si elle revient.

cela m'arrive sur 1.9.2 sur mac sur le nœud 10

Pareil ici. Fil 1.9.2, nœud 10.6.0 sur High Sierra.

@bestander ce n'est pas un problème Windows. Je peux reproduire sur mon Mac avec Yarn 1.9.4. Ce numéro devrait être rouvert.

@davidgoli , mieux vaut ouvrir un nouveau numéro, c'est un nouveau et devrait être trié séparément

Le fil est assez lent pour n'importe quel environnement dans lequel je l'ai exécuté. Debian, Mac, Windows. Le nouveau numéro était ouvert? ou le RFC qui se débarrasse de node_modules résoudra cela?

J'ai le même problème, je passe déjà à npm mais j'ai toujours un bug

J'ai également le même problème avec Yarn. Une solution trouvée?

Il s'agit d'un double du n ° 990, il existe un tableau de comparaison et il semble que les dernières versions de Yarn aient fait de bons progrès.
Si le problème persiste, veuillez déposer un nouveau problème avec les étapes de repro et une comparaison avec le dernier npm

Ce n'est pas un doublon, ce problème ne concerne pas uniquement Windows. Ouvrir un nouveau numéro entraînerait une perte de contexte.

J'ai le même problème!

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

Vagrant 2.2.4
Invité: Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
Hôte: MacOS 10.14.5 Mojave

fil 1.16.0
npm 6.9.0

MacBook Pro (Retina, 13 pouces, début 2015)
Processeur Intel Core i5 2,7 GHz
Mémoire 16 Go DDR3 à 1867 MHz

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.

En fait, je ne peux pas exécuter yarn install sans perdre plus de 25 minutes de productivité. C'est absurde. Je n'achète pas qu'il s'agit d'un problème Windows. Il me semble très probable qu'il y ait un problème lors de l'exécution dans un environnement virtualisé. Peut-être à voir avec les dossiers synchronisés / la vérification de l'état des fichiers sur le système d'exploitation invité?

fil v1.17.3
nœud v10.16.3
npm 6.9.0

les fenêtres

J'ai essayé de placer l'emplacement du dossier de mon projet d'application dans la même section de disque que yarn cache dir .
répertoire cache fil -> C: UtilisateursAppDataLocalYarnCachev4

Le résultat:
ancien emplacement -> D: myApp Done in 747.17s.
nouvel emplacement -> C: myApp Done in 488.97s.

C et D sont le même disque physique.

Mac

Cependant, Mac est plus rapide que Windows Done in 121.37s

Je pense que le goulot d'étranglement est la vitesse de lecture / écriture du disque?

OS X 10.15
fil v1.22.4
nœud v12.13.0
npm v6.12.0

Je suis toujours en train de vivre cela. Le projet se trouve dans une image disque chiffrée montée. L'installation d'un seul paquet prend plusieurs minutes avec un package.json relativement petit. Je ne l'ai pas comparé, mais npm se sent beaucoup plus rapide.

Edit: Il s'est avéré que le fait de changer le dossier de cache par défaut de Yarn pour qu'il soit sur le même volume crypté a résolu ce problème pour moi.

Je viens juste d'être touché par ça aussi et je cours:

Système d'exploitation: Ubuntu 18.04.2
Fil: 1.22.4
Nœud: 14.7.0
NPM: 6.14.7