Yarn: Paquets natifs reconstruits à chaque fois

Vous ne pouvez pas reproduire cela sous Mac OSX (10.11.6), il pourrait donc s'agir d'un problème spécifique à Ubuntu?

Je pourrais repro sur Windows 10, mais une seule fois. La deuxième fois que j'ai lancé "yarn", il n'a pas reconstruit les bibliothèques natives. Étrange.

Je jouais encore un peu avec et je suis venu avec quelques détails supplémentaires:

1. Si j'exécute yarn add leveldown bcrypt , leveldown sera compilé comme premier élément de la liste et le hachage dans node_modules/.yarn-integrity sera égal à 595306... quand il sera terminé (cut par souci de concision; je suppose que c'est une somme de contrôle qui détermine si quelque chose doit être fait). Maintenant, si je lance à nouveau seulement yarn , les deux paquets seront reconstruits avec bcrypt compilé en tant que premier dans la liste (l'ordre est différent). La somme de contrôle qui en résulte sera égale à cbe480... . L'appel ultérieur de yarn ne reconstruira pas les paquets et la somme de contrôle restera la même. Cela contredit mon rapport original (j'ai probablement fait une erreur quelque part) mais correspond à ce que @ Daniel15 voyait.
2. Lorsque j'inverse l'ordre des paquets dès le début ( yarn add bcrypt leveldown ), bcrypt sera le premier de la liste et la somme de contrôle qui en résulte sera égale à cbe480... immédiatement. L'appel ultérieur de yarn ne reconstruira pas les packages.
3. Le package bcrypt se terminera toujours en premier (comme prévu car il n'y a tout simplement pas grand chose à compiler) quelle que soit la position dans la liste.

Je ne suis pas du tout familier avec les composants internes mais il me semble que l'ordre dans lequel les packages sont compilés importe et ils ne sont tout simplement pas triés lors de la première installation (et ils _ sont_ triés lors de l'appel ultérieur de yarn ) qui affecte la somme de contrôle d'une certaine manière.

Merci d'avoir enquêté! Cela semble être une bonne piste. Le hachage est écrit ici: https://github.com/yarnpkg/yarn/blob/f04b157a0162114de7252b682ecf4b66895d7e87/src/cli/commands/install.js#L581 -L583. Cela pourrait valoir la peine de déboguer ce code et de voir ce qui est différent dans le fichier de verrouillage, car le hachage dans .yarn-integrity est basé sur le fichier de verrouillage.

Cela pourrait valoir la peine de déboguer ce code et de voir ce qui est différent dans le fichier de verrouillage, car le hachage dans .yarn-intégrité est basé sur le fichier de verrouillage.

Je m'en doutais mais ce qui m'a déconcerté, c'est le fait que le fichier de verrouillage ne change pas, c'est toujours le même. C'est juste le hachage dans .yarn-intégrité qui change.

$ 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

J'ai le même problème: j'utilise aussi bcrypt. Chaque fois que j'installe de nouveaux modules ou que je mets à niveau des modules existants, je dois exécuter npm rebuild pour rendre mon application exécutable.

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

Je ne peux plus reproduire le numéro original. Il semble avoir été corrigé: +1 :. @ Daniel15 Pouvez-vous confirmer?

@hustcer Je ne pense pas que ce soit le même problème. Vous voudrez peut-être tester avec la dernière version et signaler un nouveau bogue si cela ne fonctionne toujours pas pour vous.

@jiripospisil Merci, ça va maintenant après la mise à niveau vers le fil v0.17.4.

Je vois toujours ceci, ou quelque chose de très similaire, sur 0.18.1. Incidemment, c'est aussi un nivellement qui continue d'être reconstruit à plusieurs reprises. En utilisant leftpad comme un package sans dépendances (et qui ne dépend pas de leveldown) à des fins de démonstration, les étapes de repro sont les suivantes:

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

Ma sortie lorsque je lance ceci suit. Notez que la suppression du pavé gauche prend près de 40 secondes, dont la majorité consiste à reconstruire le leveldown. Cela se produit de manière cohérente, avec et sans leveldown ou leftpad dans le cache Yarn, mais uniquement pendant remove et jamais 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.

Versions:

Nœud v7.3.0
Fil 0.18.1
OS X El Capitan (10.11.6)

Veuillez rouvrir car cela se produit toujours.
Je viens de faire yarn add redux et il a reconstruit bcrypt , node-sass et plusieurs autres.

Nœud v6.9.4
Fil v0.20.3
Windows 10

@seansfkelley J'ai suivi vos pas avec la dernière version et cela a fonctionné. Pouvez-vous réessayer?

/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 Pourriez-vous s'il vous plaît ajouter quelques étapes de reproduction? J'ai essayé quelques combinaisons mais cela a fonctionné.

Nœud 7.3.0
Fil 0.20.3
MacOS 10.12.3

@jiripospisil Je n'ai aucune étape de reproduction à fournir, le simple fait d'installer un paquet supplémentaire amène le fil à tout lier et à reconstruire.

Voici le résultat de l'ajout d'un package (le fichier de verrouillage existe déjà):

Lier les dépendances:

Reconstitution:

@jiripospisil Je vois toujours cela, mais lors de ma repro, je me suis fait trébucher car il semble que leveldown (ou une dépendance de celui-ci) ait peut-être commencé à expédier un binaire compatible OS X, de sorte que les temps d'installation ont chuté de manière suspecte de 50s à 3s. Si vous êtes sous OS X et que vous avez spécifiquement yarn add [email protected] au lieu de seulement yarn add leveldown , vous devriez voir le même comportement qu'avant.

J'ai une dépendance indirecte sur ttf2woff2 , qui se reconstruit également à chaque fois.

Cependant, il ne se reconstruit qu'à chaque fois qu'il y a un changement de yarn.lock . Soit, yarn avec un nouveau yarn.lock , yarn upgrade , yarn upgrade-interactive Dans le cas yarn upgrade-interactive , si les deux devdeps et les deps réguliers ont été mis à jour, ttf2woff2 est reconstruit deux fois (!).

Je vois également ce problème, même si je n'ai pas pu le reproduire avec les étapes ci-dessus. Cependant, je peux le reproduire avec ces étapes:

yarn install pouchdb-node
````

which builds leveldown. Then if I add another package:

fil ajouter co
''

puis à nouveau, il construit le leveldown.

Le package que j'ajoute ne semble pas avoir d'importance, il reconstruit toujours le leveldown.

J'utilise Yarn v0.21.3, Windows 10 et Node v7.7.1

Je vois cela aussi. J'utilise BuckleScript (bs-platform) ...

Je rencontre également ce problème avec sharp . Chaque fois que j'exécute yarn add ou yarn remove , sharp est reconstruit, même avec des packages non natifs.

Testé en fil v0.21.3, Node 7.0.0, sous Windows 10 et Ubuntu Linux 16.04.

Voici les dépendances de package.json , si cela aide:

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

voir aussi ceci avec bs-platform

Également expérimenté avec ttf2woff2 chaque appel à yarn add reconstruit ttf2woff2 même s'il n'a pas été publié depuis plus d'un an.

J'ai aussi ça avec couchbase

edit: semble être corrigé dans 0.23.2

Cela m'arrive encore sur 0.23.2 ( argon2 et node-sass sont reconstruits chaque fois que j'ajoute / supprime un paquet non lié comme moment qui n'a pas de dépendances)

Système d'exploitation: Windows 10
Nœud: 7.9.0
Fil: 0.23.2

Pour ajouter un peu plus de couleur, ma perception de cela se produisant sur yarn add <some-package> était beaucoup plus grande que la réalité car de nombreux cas pour moi ont été déclenchés en combinant avec yarn remove <unrelated-package> immédiatement avant en raison du force: true sur cette ligne .

Certainement pratique de réutiliser la logique d'installation dans remove pour générer le fichier de verrouillage, mais ce serait bien s'il ne venait pas avec tous les bagages d'une installation forcée :)

Pour moi, cela a recommencé à se produire lorsque je suis passé à la version 0.23.x. Je suis revenu à 0.21.3 et il ne se construit plus à chaque fois. Cela a également conduit à ce problème où mon adresse IP a été bloquée par unicode.org après la mise à niveau de quelques packages d'affilée https://github.com/dodo/node-unicodetable/issues/16

Alors que la 0.21.3 ne reconstruit pas tous les packages lors de l'ajout d'un nouveau package, elle reconstruit tous les packages lors de la suppression. Et il semble que le fil ne le considère pas comme un échec si la reconstruction échoue.

Pour moi, passer à 0.21.3 n'a pas aidé. bs-platform est reconstruit à chaque ajout / suppression.

Voir cela sur macOS avec Yarn 0.23.4. Reconstruit sqlite3 chaque fois que j'exécute 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.

Voir ce problème avec Ubuntu 16.04LTS, avec le dernier fil v0.24.6, avec le nœud 8.1.2

Je vois gdal , node-sass reconstruire à chaque fois que j'ajoute un module, cela fait que yarn add prend beaucoup plus de temps que nécessaire.

Je vois cela aussi, c'est super ennuyeux sur un Raspberry Pi Zero W où la construction de packages (comme bleno) peut prendre plusieurs minutes.

Je vois toujours cela avec Yarn v0.27.5 et uws . Chaque fois que quelque chose change dans mes packages, uws est reconstruit.

La seule chose intéressante que je peux voir à propos de uws est qu'il n'a pas de champ de dépendances dans package.json .

Cela devient une véritable frustration pour moi ces derniers jours. J'ai eu windows-build-tools installé globalement à une étape (n'a vraiment besoin de se construire qu'une seule fois pour configurer l'environnement de développement Windows pour les packages natifs) qui ne cessait de se reconstruire à chaque fois que j'ajoutais un package. Comme vous pouvez l'imaginer, cela a pris un certain temps et j'ai finalement réalisé que je n'avais plus besoin de l'installer et je l'ai supprimé.

Maintenant, il semble que node-sass continue de vouloir reconstruire sur un autre projeté lors de l'ajout de packages.

Ce comportement se produit à la fois sur yarn add et yarn remove pour moi. Aucune reconstruction n'est nécessaire pour ces étapes, car les packages natifs ne sont construits qu'une seule fois selon la version Node?

Edit: Utilisation de Node v8.2.1 et Yarn v0.27.5 sous Windows 10.

Je ne peux pas compter les fois où uws été reconstruit pour moi :) Notez que uws
n'a aucune dépendance et il manque même le champ dans package.json

Le lun 31 juillet 2017, 22:50 Paul Myburgh [email protected]
a écrit:

Cela devient une véritable frustration pour moi ces derniers jours. j'avais
windows-build-tools installés globalement à une étape (il suffit
se construire une seule fois pour configurer l'environnement de développement Windows pour le natif
packages) qui se reconstruisaient à chaque fois que j'ajoutais un package. Comme
vous pouvez imaginer que cela a pris un certain temps et j'ai finalement réalisé que je ne l'ai pas fait
besoin qu'il soit installé et supprimé.

Maintenant, il semble que node-sass continue de vouloir reconstruire sur un autre projeté
lors de l'ajout de packages.

Ce comportement se produit à la fois sur l'ajout de fil et la suppression de fil pour moi. Sûrement non
la reconstruction est nécessaire pour ces étapes car les packages natifs ne sont construits que
une fois selon la version Node?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-319192291 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AADWlgSNhi-V9-yGWsWHBDFYdyJW8Arjks5sTj4UgaJpZM4KVN87
.

Je suis sur 0.27.5 et continue de voir ce comportement avec bs-platform .

C'est assez frustrant, idem ici avec bs-platform .

Bon sens du droit là-bas… Que diriez-vous d'un PR Tim?

Le mar 22 août 2017, 10:44 Tim Shnaider [email protected]
a écrit:

FFS peut-il être corrigé s'il vous plaît.
Au moins, fournissez une option de ligne de commande ou un paramètre d'environnement pour le désactiver.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-323960245 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AADWltQedG4owTlcC8koC4RL-vTiCE0Hks5sapTbgaJpZM4KVN87
.

Cela ne semble pas avoir été mentionné jusqu'à présent, mais je peux aussi reproduire ce bogue avec yarn global list .

Étapes à suivre pour reproduire:

1. Utilisez un nouvel env global:: avertissement: exécutez ceci uniquement si vous savez ce que vous faites

   rm -rf ~/.config/yarn/
   

2. Ajoutez un package problématique (_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. Exécutez yarn global list et voyez certains paquets natifs en cours de recompilation

4. Répétez autant que vous le souhaitez, yarn global list recompilera toujours ces paquets natifs
5. 😭

J'espère que ça aide.

ℹ️ MacOS 10.12.6 avec Yarn 0.27.5 installé via Homebrew.

Le droit n'est pas nécessaire, mais je peux comprendre la frustration. Cela fait perdre beaucoup de temps à beaucoup de monde (les longues réinstallations s'additionnent avec le temps et interrompent le flux). Bien sûr, vous pouvez dire "faire une demande d'extraction" - et c'est juste. Mais ce serait un processus d'apprentissage en plus de changer potentiellement quelques lignes de code ... Ce que nous espérons, c'est que les personnes qui connaissent les tenants et les aboutissants de ce projet pourraient donner la priorité à ce problème sur la prochaine version car il semble plutôt majeur (et potentiellement une solution facile? Empêchez la réinstallation des binaires si la version de Node n'a peut-être pas changé).

Cela fait presque un an maintenant qu'il a été signalé pour la première fois.

J'espère que je n'ai pas le droit de dire cela ... Je voudrais ajouter que je suis très reconnaissant pour ce projet et l'utilité qu'il m'apporte déjà. Ce problème a été l'un des très rares problèmes que j'ai rencontrés.

EDIT: Je viens de faire un yarn remove pour un paquet aléatoire et il a essayé et (cette fois) n'a pas réussi à reconstruire mes binaires. L'effet secondaire étant que mes binaires sont complètement absents maintenant et il semble que la seule façon de résoudre ce problème soit avec un npm rebuild . Donc, non seulement il semble que ce problème provoque des reconstructions inutiles - mais s'il échoue ce processus, il semble que vous deviez recourir à npm pour le réparer à nouveau.

Je constate le même comportement que @zhangjyr et @lostpebble. Lancer yarn add fonctionne bien mais yarn remove entraîne la reconstruction des packages natifs.

Mac Sierra 10.12.6
Fil 0.27.5

Je vais essayer de voir ce que je peux faire à ce sujet puisque cela m'affecte également. Cela dit, il n'est pas si difficile de contribuer à Yarn, donc si quelqu'un veut envoyer un PR, essayez-le et nous essaierons de vous soutenir autant que possible.

Je ne pourrai pas travailler dessus pendant quelques semaines.

Je vois cela aussi.
Travailler sur site construit sur gatsby. TOUTE opération de fil entraîne une reconstruction.
Essayez de créer un site avec Gatsby et de jouer avec. J'espère que cela t'aides

Voir cela dans un projet utilisant gatsby:
fil 1.0.2
nœud 7.10.1
ubuntu 16.04

Ce problème devient très sérieux maintenant. Non seulement mes binaires sont toujours reconstruits. Mais il arrive souvent que mes binaires soient complètement supprimés après un yarn add ou yarn install (après avoir changé les numéros de version d'un paquet dans package.json pour mettre à jour / annuler un module). Et peu importe combien je lance yarn install ou yarn install --check-files par la suite, ces binaires sont simplement perdus et partis et ne reviennent jamais. La seule façon de les récupérer est avec un npm rebuild .

On commence à avoir l'impression que le fil ne connaît pas du tout l'état des packages natifs. S'ils sont déjà installés / construits, ou s'ils ne sont pas installés / construits correctement.

Y a-t-il peut-être eu des progrès à ce sujet?

Je pense que l'ajout récent du champ artifacts au fichier d'intégrité du fil par @arcanis aiderait à résoudre ce problème. Pas encore de progrès mais ouvert aux PR :)

J'ai un problème similaire avec bs-platform lors de l'installation de packages dans mon projet reasonml

Idem ... littéralement chaque yarn add reconstruira le projet gyp.

Cela se produit ici aussi.
(fil 1.2.1)

Je vois cela avec node-sass .

Cela m'arrive avec Cypress par exemple.

nœud -v
v8.8.1
fil -v
1.2.1

✋ Au lieu d'écrire «Moi aussi» sans informations supplémentaires, utilisez la fonction +1 de Github sur le post supérieur . Chaque fois que vous écrivez un commentaire «moi aussi», 35 abonnés sont inutilement avertis.

+1

Cliquez simplement sur Subscribe si vous souhaitez recevoir des mises à jour. J'espère que tout le monde veut être averti quand il est résolu, mais pas quand quelqu'un de nouveau fait face à ce problème aussi.

@BYK pouvez-vous s'il vous plaît verrouiller le fil, et le rendre disponible uniquement pour les propriétaires.

J'étudie actuellement ce problème et j'essaie de le réduire à un cas de test minimum reproductible. Un "excellent" package pour démontrer ce problème est htmlstrip-native - il faut quelques minutes pour être compilé, vous ne pouvez donc pas le manquer.

J'aimerais que quelqu'un d'autre essaie ceci package.json dans un dossier vide:

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

Essayez d'exécuter ces commandes:

yarn
yarn upgrade [email protected]

Sur ma machine, avec le dernier fil 1.2.1, la commande upgrade entraîne une reconstruction de htmlstrip-native qui prend une éternité. Yarn ne devrait pas reconstruire cela car la mise left-pad jour de htmlstrip-native ou ses dépendances.

Maintenant, essayez npm :

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

Sur ma machine, la deuxième commande (correctement) n'entraîne pas une nouvelle reconstruction de htmlstrip-native .

EDIT :

OK, donc après beaucoup de débogage, il semble que ce comportement soit intentionnel. En suivant le code, il semble, par exemple, que yarn upgrade [email protected] entraîne les étapes suivantes:

1) Le module upgrade est appelé, qui exécute une opération new Add() pour left-pad .
2) Add.init() appelle sa superclasse, Install.init()
3) Install.init() file une étape rebuildingPackages
4) Dans PackageInstallScripts.init() il collecte simplement _tous_ les paquets et les ajoute au workQueue à reconstruire.
5) PackageInstallScripts découvre alors qu'il existe une commande d'installation pour htmlstrip-native et l'exécute simplement - c'est la reconstruction native super lente que nous voyons tous.

D'après tout ce que j'ai vu jusqu'à présent, il ne semble y avoir aucune logique qui vise à filtrer les paquets qui n'ont pas "besoin" d'être reconstruits. Il s'agit simplement de tout reconstruire, comme indiqué dans la sortie de la console.

J'adorerais que quelqu'un de l'équipe Yarn intervienne ici - si ce comportement est vraiment intentionnel, je vous recommande de fermer ce numéro!

Pour ma situation personnelle, je vais simplement échanger ma dépendance htmlstrip-native car il n'y a aucune raison que cela prenne des minutes à construire (c'est comme, quelques petits fichiers .c ). Le reste de mes déps natifs se construit rapidement, donc ce n'est pas grave si cela arrive tout le temps.

Cela ressemble à un effet secondaire non intentionnel de la conception, mais peut-être que quelqu'un sur @ yarnpkg / core peut le commenter. Je ne pense pas qu'il soit destiné à reconstruire des paquets qui n'ont pas besoin d'être reconstruits.

Ce n'est pas intentionnel, c'est probablement juste plus facile à mettre en œuvre de cette façon.
Il y a un commentaire ci-dessus de BYK qui dit que ce problème est à la recherche d'un PR:
https://github.com/yarnpkg/yarn/issues/932#issuecomment -332498506

Les packages natifs ne sont certainement pas assez courants pour apparaître comme la priorité la plus élevée pour Yarn, cependant Yarn a la capacité de ne pas reconstruire les packages à chaque installation.
Cela semble être un bogue qui devrait être simple à corriger, envoyez un PR.
Il peut y avoir des mises en garde car Yarn ne peut pas savoir avec certitude si un paquet construit a pu être corrompu, c'est pourquoi il réexécute avec impatience les scripts d'installation maintenant.

Il existe un fork de Yarn qui est utilisé par l'équipe derrière Reason https://github.com/esy-ocaml/esy-install qui fonctionne autour de nombreux problèmes de compilation native car les dépendances Reason / Ocaml nécessitent une compilation lourde.
À mesure que cette approche mûrit, j'espère qu'il sera possible de fusionner les changements en amont.

Donc, fondamentalement, les packages natifs sont reconstruits car soit:

1) L'indicateur force=true a été défini, ou
2) Le paquet a été marqué fresh=true .

Il semble qu'avec certaines commandes (comme upgrade et remove ), l'indicateur force est mis à true "juste au cas où". Cet indicateur promet de «reconstruire tous les paquets indépendamment du fait qu'ils aient changé», donc il n'a pas de sens d'ajouter du code de détection de changement car cela briserait cette promesse.

Donc, pour résoudre ce problème, il semble que nous devrons remettre en question les hypothèses des différents endroits du code qui définissent force=true .

Le premier que j'ai suivi se produit lors de l'exécution de yarn upgrade whatever . Il a été introduit dans ce commit dans le cadre de # 2780 par @juanca. Les notes de commit disent:

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

Peut-être que @juanca ou quelqu'un de plus familier avec l'histoire de

@nfarina merci, cela apporte de la clarté. Pour les mises à niveau, peut-être que nous voulons vraiment forcer la construction de packages natifs (s'ils sont en cours de mise à niveau). Mais pour les installations (yarn add), je dirais que nous devons légitimement contester, comme vous l'avez dit, l'hypothèse selon laquelle les packages natifs déjà installés se reconstruisent quand quelque chose d'autre est installé.

Je suppose que l'indicateur force est défini de sorte que le résolveur Yarn n'ignore pas la dépendance existante car l'ancienne version est dans yarn.lock.

Je pense que c'était une solution rapide pour faire fonctionner la mise à niveau.
Une bonne manière serait de passer un autre drapeau qui n'affecte que la résolution des paquets spécifiés et ne sera pas aussi nucléaire que force .
Envoyez un PR :)

Peut-être que @juanca ou quelqu'un de plus familier avec l'histoire de

Correct, je travaillais uniquement avec l'API Add - elle ne fait (n'a rien fait?) Lors de l'ajout d'un package existant.

Je recommande également d'utiliser une meilleure technique pour contrôler le flux procédural.

J'utilise du fil sur mon raspberry pi zero dans un projet qui dépend de node-opencv. Chaque fois que j'ajoute / supprime / mets à jour un paquet sans rapport, je dois attendre 35 minutes pour la reconstruction.

@ Torsten85 , je l'utilise aussi sur pi, ouais les reconstructions inutiles sont quelque chose que nous devons aborder.
Pouvez-vous fournir un script de repro pour vos reconstructions?

idem ici, sur lubuntu 17.10, quand j'utilise du fil, en développement avec https://github.com/mui-org/material-ui

chaque yarn add/remove (-D) <pkg> tout reconstruire, comme une nouvelle installation, prend plus d'une minute

Est-ce ainsi que npm le gère également? Sinon, serait-il une solution de contournement possible pour basculer temporairement?

se passe aussi ici

• nœud 9.2.0
• fil 1.4.0

chaque fois que j'ajoute une dépendance, des modules comme bcrypt ou couchbase sont reconstruits à chaque fois

Salut tout le monde, je travaille sur un petit hack https://github.com/yarnpkg/yarn/pull/5314.
L'idée est de mettre en cache un package intégré dans un miroir hors ligne pour éviter d'exécuter des scripts d'installation tout le temps.

Donc, si vous utilisez offline-mirror et exécutez yarn add node-sass :

1. yarn construirait et installerait node-sass comme d'habitude,
2. après l'exécution des scripts d'installation, il générera node-sass-v4.7.2-darwin-x64-57.tgz partir du dossier node_modules/node-sass modifié
3. La prochaine fois que vous exécuterez yarn install sur la même plate-forme, il décompresserait simplement node-sass-v4.7.2-darwin-x64-57.tgz au lieu de l'original et n'exécutera pas de scripts d'installation

Cela ne fonctionnera pas pour tous les cas, mais cela pourrait être une solution pour les systèmes CI hors ligne dans lesquels vous ne voulez pas que les packages parviennent sur Internet et exécutent les mêmes scripts d'installation à chaque fois.

J'essaie d'installer dactylographié en tant que package global, et yarn passe tout son temps à reconstruire des trucs au lieu d'installer ce dont j'ai vraiment besoin maintenant.

Je suis passé au fil en pensant que c'est plus rapide et meilleur. J'ai supprimé toute trace de npm (sauf ce qui vient avec l'installation du nœud); et réinstallé tous les packages globaux sur yarn.

Yarn teste maintenant ma patience en me faisant attendre 1 à 15 minutes pour une installation simple du paquet. Yarn devrait être suffisamment intelligent pour installer ce qui est demandé en premier avant de reconstruire d'autres éléments, à moins que le package demandé ne dépende explicitement de l'un des packages natifs qui nécessite une reconstruction.

Environnement:

• Nœud: 9.4.0
• Fil (global): 1.3.2
• macOS Sierra: 10.12.6
• Macbook pro 15 pouces
  
  
  
  • Mémoire: 16 Go
  
  
  • Processeur: 2 GHz - Intel Core i7
  
  
  • Stockage: magentic (beaucoup d'espace libre)
  
  
  • Applications en cours d'exécution au moment de l'installation: Firefox (6 onglets), Mail.app et iTerm (avec 2 onglets)
  
  

Journaux

La récupération des packages prend beaucoup de temps

typographie de mise à niveau globale de fil
fil global v1.3.2
[1/4] 🔍 Résolution des packages ...
[2/4] 🚚 Récupération des packages ...
[############################################## ############ -------------------------------------- -------------------------------------------------- -----------------------------------------------] 673 / 2166

La liaison des dépendances est bloquée sans aucune progression pendant quelques minutes

typographie de mise à niveau globale de fil
fil global v1.3.2
[1/4] 🔍 Résolution des packages ...
[2/4] 🚚 Récupération des packages ...
[3/4] 🔗 Lier les dépendances ...
[------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------] 0/2566

Reconstruire tous les paquets - prend beaucoup de temps

typographie de mise à niveau globale de fil
fil global v1.3.2
[1/4] 🔍 Résolution des packages ...
[2/4] 🚚 Récupération des packages ...
[3/4] 🔗 Lier les dépendances ...
[4/4] 📃 Reconstruction de tous les paquets ...
[12/17] ⠐ websocket
[2/17] ⠐ expresso: vérification de l'option gcc pour accepter ISO C99 ...
[8/17] ⠐ serialport: en utilisant [email protected] | darwin | x64
[6/17] ⠐ maintenant:> Pour le code source, consultez: https://github.com/zeit/now-cli

typographie de mise à niveau globale de fil
fil global v1.3.2
[1/4] 🔍 Résolution des packages ...
[2/4] 🚚 Récupération des packages ...
[3/4] 🔗 Lier les dépendances ...
[13/17] ⠈ sans serveur
[13/17] ⠂ sans serveur
[14/17] ⠠ solgraphe
[14/17] ⠁ solgraphe
[14/17] ⡀ solgraphe
[- / 17] ⠈ en attente ...
[- / 17] ⠄ en attente ...
[- / 17] ⠠ en attente ...
[- / 17] ⠈ en attente ...
[- / 17] ⠄ en attente ...
[- / 17] ⢀ en attente ...
[- / 17] ⠈ en attente ...

J'attends :-)

un autre effet secondaire est que les bibliothèques qui téléchargent et mettent en cache les précompiles sont également effacées et doivent être téléchargées à nouveau: à savoir le cache de nwjs-builder-phoenix des sdks de la cible de construction

1. Le package natif est toujours reconstruit lors de la mise à jour d'une version de package qui n'est pas un package natif.

Yarn cache-t-il le binaire dans le global comme npm?

Cela commence à me frustrer un peu d'avoir à reconstruire nwjs dans chaque installation simple. Ça n'a aucun sens

je vois ça aussi. uws est reconstruit chaque fois que je fais une opération d'ajout / suppression. fil v1.3.2

Salut @bestander. Nous avons essayé le # 5314 sur le monorepo de notre société, mais cela n'a eu aucun effet sur l'arrêt de la reconstruction de certaines dépendances pour nous. Nous avons activé yarn-offline-mirror et pack-built-packages dans .yarnrc comme indiqué dans les tests ajoutés.

Le point crucial est que l'exécution de yarn prend toujours environ 40 à 50 secondes pour nous, même si la commande que nous avons exécutée directement auparavant était également yarn .

@ bazyli-brzoska, j'ai changé le drapeau pour qu'il soit plus explicite et j'ai oublié de mettre à jour la description.
Pouvez-vous essayer avec le drapeau experimental-pack-script-packages-in-mirror défini comme "vrai"?

Y a-t-il des progrès à ce sujet? Je vois que la pull request est déjà fusionnée et qu'elle est dans la dernière version 1.5.1. Je suis sur 1.5.1 et rien n'a changé pour moi. Néanmoins, j'envisage de revenir à npm, car attendre 322.70s ou 282.69s ou même 683.41s (ce sont vraiment mes trois derniers yarn add s) pour installer un petit plugin rollup ou un lodash ou bien, à peu près tout, est tout simplement fou.

Ce serait génial si des mises en garde majeures comme celles-ci figuraient sur votre README.md. Les utilisateurs installent yarn parce qu'il est prétendument "plus rapide" et faire cette transition de npm à yarn n'est pas une petite étape, donc ce serait bien s'il y avait un avertissement préalable pour les développeurs, afin qu'ils puissent plutôt y réfléchir une fois de plus, avant de convertir leurs scripts, polluant leurs globaux et apprenant le fil cli.

Je pensais que c'était juste un problème avec mon ancienne machine 32 bits, mais après l'avoir vu la 237ème fois, je l'ai googlé et oh, le fil n'est tout simplement pas plus rapide. Génial.

Désolé d'être probablement méchant, mais je pense que vous ressentez la frustration.

Nous acceptons les contributions.

Cela étant dit, quelque chose à garder à l'esprit concernant les paquets qui sont reconstruits quand ils n'en ont pas "besoin": les étapes de construction sont exécutées après l'installation des dépendances. Cela signifie que les scripts de construction sont autorisés à utiliser ces dépendances. Cela signifie que si ces dépendances changent pour une raison quelconque (ce qui peut se produire `` au hasard '', par exemple si nous avons optimisé deux versions compatibles d'un package en une seule), nous devons en fait réexécuter les étapes de construction même si ces dépendances ne sont pas réellement utilisé lors de la construction (car comment pourrions-nous savoir?).

Ce n'est donc pas vraiment un problème facile. Au moins une partie du problème vient de la conception package.json elle-même. Parlez-moi de la frustration 🙂

@arcanis je ne comprends pas cette partie:

même si ces dépendances ne sont pas réellement utilisées lors de la construction (car comment pourrions-nous savoir?).

Je pensais que la conception de YARN devait garder les dépendances statiques + version (yarn-lock) et qu'il n'y aurait donc pas de "mises à jour" aléatoires.
Même si le package json donne un arbre complet, alors pourquoi dites-vous «comment pourrions-nous savoir»? Une fois l'arborescence résolue, il est très facile de dire si l'une des dépendances (même celles de niveau profond) pour construire X a changé ou non.

Disons que j'ai une dépendance foo qui dépend de babel-core et left-pad@^1.0.0 , et que cette dépendance foo a un script de construction qui exécute babel sur son fichier d'index .

Après avoir exécuté yarn add foo dans mon dossier de projet, je finis par avoir [email protected] dans les node_modules, non? Supposons maintenant qu'une nouvelle version du pavé gauche soit publiée ( 1.1.0 ), et je souhaite l'utiliser dans mon projet. Je vais lancer yarn add left-pad , qui se résoudra alors en latest , soit 1.1.0 .

Maintenant, ce qui peut arriver, c'est que Yarn "verra" qu'il y a deux copies du pad gauche dans l'arbre, et verra également qu'elles pourraient être optimisées: après tout, foo dépend de left-pad@^1.0.0 , donc 1.1.0 est également compatible. Il supprimera donc la version précédente et n'utilisera que 1.1.0 . Comme la dépendance a changé, nous devons réexécuter le script de construction car Yarn n'a aucun moyen de savoir que left-pad est une dépendance d'exécution plutôt qu'une dépendance de construction .

Maintenant, vous pourriez demander "mais pourquoi ne pas simplement sauter la reconstruction lorsque les dépendances transitives ont changé?". La réponse est que certains packages (en particulier les packages natifs) ont des dépendances qui affectent radicalement la manière dont ils sont construits. Quand cela se produit, nous voulons vraiment, vraiment reconstruire ces paquets, sinon nous nous retrouverions avec des artefacts incompatibles.

@arcanis , je pense que vous avez mal compris le problème. le problème ici est que ces paquets natifs sont recréés à chaque fois, même lorsque yarn est exécuté deux fois (ou plus) en succession rapide. cela n'a rien à voir avec la mise à jour des dépendances - il se reconstruit toujours.

@Spongman Je suis d'accord avec votre dernier commentaire. Mais comme @Spongman l'a correctement mentionné, la reconstruction se produit à chaque fois . Même si vous ne faites que yarn && yarn - vous obtenez deux reconstructions complètes , malgré le fait que rien n'a changé dans la structure des dépendances.

J'ai essayé d'exécuter yarn add leveldown bcrypt && yarn && yarn comme dans l'OP et je n'ai obtenu qu'une seule version: / Avez-vous une commande que je peux utiliser pour reproduire ce comportement?

Vous pouvez essayer par exemple:

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)

(c'est sous Ubuntu 14 LTS)

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

yarn & yarn 

Ne provoque pas deux reconstructions, mais l'exemple avec le socket.io, l'ajout de react, la suppression de react provoque deux reconstructions

J'ai essayé l'exemple socket.io avec yarn v1.5.1 et je n'ai pas eu de reconstructions lors de l'utilisation de la nouvelle fonctionnalité pour mettre en cache les versions natives. Pour ce faire, vous devez utiliser le cache hors ligne. Dans mon ~/.yarnrc j'ai:

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

Lorsque j'essaye en tant qu'autre utilisateur sans cette configuration, il se reconstruit à chaque fois.

Oui, pas de reconstruction maintenant lorsque ces options sont ajoutées.
Mais si seulement experimental-pack-script-packages-in-mirror true , il se reconstruit toujours.
Pourquoi ne pas définir yarn-offline-mirror sur un chemin par défaut comme "~ / .yarn / cache".

Encore expérimental, mais c'est une suggestion intéressante (cc @bestander). Je suppose que le problème que j'ai avec cela est que personnellement, je n'aime pas l'idée d'activer les choses sans le consentement explicite de l'utilisateur. Cela a aussi d'autres implications: que signifierait avoir yarn-offline-mirror mis à false , et experimental-pack-script-packages-in-mirror à true ? experimental-pack-script-packages-in-mirror devrait-il remplacer les paramètres de yarn-offline-mirror ? Un peu déroutant imo.

Cela étant dit, le bogue de la reconstruction de uws lors de l'ajout de left-pad est un peu ennuyeux, et les paramètres experimental-pack-script-packages-in-mirror sont une solution de contournement. Je ne suis pas sûr que j'aurai la bande passante pour examiner cela dans la semaine prochaine, mais si quelqu'un est intéressé à trouver un correctif, ce serait assez impactant.

@arcanis Merci pour votre aimable réponse. La frustration vient de la façon dont le fil est présenté. Pour le moment, ce n'est tout simplement pas "rapide", certainement pas plus rapide que npm et un peu inutilisable dans des projets réels. Imho, il devrait y avoir une information à ce sujet ou même la solution de contournement par @skomorokh dans votre fichier README.md jusqu'à ce que cela soit corrigé. Ou supprimez simplement le "rapide" de votre description.

Je ressentirais la même frustration si le readme du repo angularjs indiquait que c'est un framework léger. Ce n'est tout simplement pas.

Il se répète toujours pour télécharger le fichier binaire aprè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

Je vais essayer de déboguer un peu là-dessus aujourd'hui. Je pense que cela pourrait être aussi simple que PackageInstallScripts ne pas vérifier pkg.fresh pour ne reconstruire que les paquets nouvellement installés. Au lieu de cela, on dirait que c'est juste en boucle sur eux tous.

Après quelques bidouilles, je commence à penser que nous reconstruisons les choses tout le temps au cas où quelqu'un rm -rf node_modules ou le module serait supprimé de là.

Nous avons une liste d'artefacts de construction détectés dans le fichier .yarn-integrity , donc je pense qu'une reconstruction ne devrait se produire que si fresh package || module destination dir does not exist || any file in integrity artifacts does not exist || --force flag was passed

C'est donc un peu plus compliqué que je ne le pensais.

J'ai juste yarn add ed moment , un package sans dépendance, à mon application de réaction à jour, il a fallu 377.97s .

Je l'ai fait à nouveau juste après cela, il a fallu 389.63s et reconstruit à nouveau les binaires.

Juste à titre de comparaison, j'ai ensuite supprimé node_modules et entré npm install :
added 1751 packages and updated 124 packages in 360.595s

Revenu à npm maintenant.

OK, quelques infos supplémentaires pour tous les yeux sur ce problème ... Je joue avec ce truc depuis un jour et demi maintenant et j'ai finalement réalisé certaines choses.

Premièrement, la plupart de ces problèmes de reconstruction sont résolus. Il y a déjà du code dans PackageInstallScripts qui ne réexécute les scripts d'installation pour un package que s'il est marqué "frais" :

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

Par exemple, si vous utilisez node-sass :

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

Les yarn install consécutifs ne se reconstruisent pas non plus.

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

... mais bien sûr, il y a quelques exceptions ...

Sur un yarn remove le drapeau force est défini (pour corriger un autre bogue, je suppose, mais c'est comme ça depuis> 2 ans), donc les reconstructions se produisent toujours.

Cependant, c'est sans doute "correct" car c'est ce que fait aussi npm:

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

Vous pouvez voir que sur uninstall sur left-pad , npm a exécuté les scripts install et postinstall pour node-sass .

Le package uws (qui est utilisé par pas mal d'autres packages, comme socket.io , browser-sync , etc ...

quelque chose pendant son processus d'installation modifie l'un des fichiers (la taille et l'horodatage sont différents).

~/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 voit un fichier qui a "changé" par rapport au cache et marque donc le paquet "frais" pour la réinstallation

Cela déclenche alors la logique ci-dessus qui réexécute les scripts d'installation car il est «frais». Yarn essaie d'être utile et de "corriger" les fichiers incorrects, mais bien sûr, il ne sait pas que le fichier a changé en raison du script d'installation. Nous devrons peut-être rechercher un moyen de résoudre ce problème, mais il est également question de changer la façon dont ces fichiers sont comparés (arrêtez d'exécuter des statistiques sur chaque fichier), de sorte que cela pourrait être résolu avec cette retouche.

Espérons que cela explique certains des cas ici où certaines personnes disent que cela fonctionne et d'autres disent que non.

Merci d'avoir plongé plus profondément là-bas, @ rally25rs.

1. Re: utilisation de force dans la commande de suppression.
   C'était clairement une correction de bogue rapide qui a atteint la correction avec une approche nucléaire IIRC https://github.com/yarnpkg/yarn/pull/323.
   Ne devrait pas être difficile de supprimer force et de contourner le problème.

2. node_modules/uws/uws_darwin_57.node : ce fichier doit être dans le champ artifacts de .yarn-integrity , puis uws ne doit pas être marqué comme non frais lors de la liaison.
   Quelque chose ne va probablement pas ici

@bestander ah bon point sur 2. Je vais essayer de voir s'il y a une façon sensée de travailler cela dans le chèque.

@stereokai Dans mon commentaire ci-dessus, je note que npm reconstruit également les paquets lors de la désinstallation / suppression, de sorte que ce cas est sans doute "correct" si vous considérez le comportement de npm comme la norme.

@ rally25rs Merci de l'avoir signalé :)

Cependant, je considère ce comportement bogué quel que soit le gestionnaire de paquets. Il est difficile de comprendre pourquoi ce type de comportement est même nécessaire pour un fonctionnement correct. Votre système d'exploitation ne réinstalle pas les programmes locaux lorsque vous en ajoutez / en supprimez un autre, car les applications sont déjà là. Je n'attendrais rien d'autre d'un gestionnaire de dépendances statiques, non?

@stereokai Je suis plutôt d'accord, c'est pourquoi j'ai utilisé l'expression "sans doute correct" 😆
Votre système d'exploitation ne change pas non plus où les autres applications sont installées lorsque vous en désinstallez une autre.

Supposons que vous ayez un arbre de dépendances comme:

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

Si vous installez ceci, il formerait la même structure de répertoires sous node_modules , car il ne peut pas hisser depB à la racine.

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

Mais de vous yarn remove depB alors la nouvelle structure dep est:

myProj
  |- depA v1
       |-depB v2

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

donc le répertoire réel dans lequel depB v2 est installé peut changer chaque fois qu'un package est ajouté ou supprimé. Ces répertoires ne sont pas simplement copiés d'un emplacement à un autre. L'ancien est supprimé et le nouveau est copié du cache vers la nouvelle destination, ce qui signifie que les artefacts de construction qui étaient dans node_modules/depA/node_modules/depB n'existeraient plus, et auraient besoin d'être reconstruits en node_modules/depB .

De même, yarn add [email protected] changerait le chemin où depB v2 est installé (en fait, je devrais tester que mon PR pour ne pas reconstruire sur yarn add fonctionne réellement dans ce cas)

Je soupçonne que c'est pourquoi ces paquets sont reconstruits à chaque fois.

Le changement réel s'est produit dans ce commit: https://github.com/yarnpkg/yarn/commit/5300b482c851e2578ac1f3aa4908be4d0289dca8
en 2016. Le fichier a été nommé uninstall.js à l'époque, mais force: true été ajouté aux indicateurs passés à install . Il ne semble y avoir rien de spécifique dans le commentaire de validation pour indiquer _why_.

Ce serait génial s'il y avait un moyen d'éviter les reconstructions dans au moins _certains_ cas.

Tout le monde est invité à travailler sur un PR. 😸Comme je l'ai souligné ci-dessus, les reconstructions ne se produisent déjà pas sur yarn install et yarn add (dans la plupart des cas). J'ai # 5470 ouvert qui devrait éliminer les reconstructions inutiles pour yarn add lorsque vous avez uws dans vos dépendances (ou d'autres paquets qui modifient ses propres fichiers lors de l'installation). Le seul cas restant que je connaisse est yarn remove .

Après avoir lu la plupart de ce fil, je ne comprends pas ce qui se passe ici.

J'ai plusieurs packages natifs en cours de reconstruction chaque fois que j'utilise yarn add pour tout autre module (non lié). Cela prend environ 20 minutes d'une charge très élevée sur les processeurs de mon ordinateur portable. Je ne peux tout simplement pas travailler de cette façon.

Apparemment, à partir de ce fil, cela pose un problème depuis 19 mois.

Est-ce un bug? Est-ce en cours d'élaboration? Y at-il un travail autour? Dois-je revenir à npm?

Dois-je revenir à npm?

oui, jusqu'à ce que # 5470 soit publié.

@vibl

Apparemment, à partir de ce fil, cela pose un problème depuis 19 mois.

Il a en fait été corrigé (principalement) il y a longtemps. Ce fil reste juste ouvert pour un cas de bord que j'ai trouvé il y a quelques semaines où le fil reconstruira un paquet si ce paquet a changé l'un de ses fichiers (il pense que le fichier est faux par rapport à ce qui était dans le téléchargement d'origine, veut donc réparer il). Et pour une discussion ouverte sur la question de savoir si remove et upgrade devraient faire une reconstruction (cela le fait en npm, mais peut-être que cela ne devrait pas)

Est-ce un bug?

Peut être. Quels packages sont en cours de reconstruction? Le seul que je connaisse qui a été un problème constant est uws , donc en savoir plus serait utile.

Est-ce en cours d'élaboration?

Le cas spécifique que j'ai mentionné ci-dessus est corrigé dans # 5470

Y at-il un travail autour?

Si le package que vous ajoutez ne contient aucun script d'installation, vous pouvez utiliser --ignore-scripts

Ou, vous pouvez vérifier la branche du PR ci-dessus et l'utiliser.

Cela prend environ 20 minutes

Sensationnel. Je suis curieux de savoir quel paquet il s'agit.

Merci de répondre.

Les packages noise-search , level-rocksdb et jq recompilent chaque fois que j'ajoute un package sans rapport avec yarn add . Mon ordinateur portable est un peu vieux, donc il faut beaucoup de temps pour les compiler en même temps.

J'ai utilisé Yarn 1.5.1 et le nœud 9.8.0.

@vibl yeesh, noise-search est certainement le coupable des longues constructions ...

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

plus de 7 min sur un MacbookPro 😢

Quoi qu'il en soit, j'ai installé noise-search puis j'ai exécuté un yarn add left-pad avec le code de # 5470 et cela n'a _pas_ causé de reconstruction, donc je pense que vous devriez être prêt à partir une fois que nous aurons fusionné 👍

Merci :-)

Dois-je revenir sur Yarn dans quelques jours, quelques semaines ou quelques mois?

Je viens de découvrir que ce bug, avec le même projet exact sur le même ordinateur portable (dual boot), ne se produit pas sous Windows 10. Mais il est présent dans les trois dernières versions de Debian, Ubuntu, Arch Linux et Fedora. Bizarre. Je n'ai pas encore essayé MacOS, mais il semble que certaines personnes aient également des problèmes là-bas.

@vibl Je ne sais pas quand sera notre prochaine version (je ne suis pas impliqué dans cette planification)

@nnmrts ouais j'ai découvert que c'est une chose spécifique au système d'exploitation. De mes commentaires dans # 5470:

sur linux avec le nœud 8, lorsque les fichiers sont copiés du cache vers node_modules, les horodatages sont mis à jour. yarn décide que les fichiers sont différents et marque la référence fraîche.
Cependant, cela ne semble se produire que sur le nœud Linux 8.
c'est parce que Node v8.5 a introduit fs.copyFile qui a fait des copies beaucoup plus rapidement. IIRC qui redirige vers la copie native du système de fichiers, ce qui expliquerait pourquoi il fonctionne différemment entre les systèmes d'exploitation et uniquement dans le nœud 8.

@ rally25rs @nnmrts Ce n'est certainement pas une chose spécifique à MacOS. Se produit également sur mon PC Win10

@stereokai Eh bien, toute cette question n'est pas spécifique. Parfois, les paquets doivent être reconstruits et les gens pensent toujours que c'est un bogue et le publient ici. Sans un référentiel solide et reproductible pour chaque système d'exploitation, nous ne pouvons rien savoir.

La mise en cache locale des modules construits (à partir de # 5314) peut aider?:

Ajoutez .yarnrc à votre projet avec les éléments suivants:

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

Après la première installation, les modules prédéfinis vivront dans ./<your-offline-mirror-path>/prebuilt . yarn.lock est également mis à jour avec des variantes prédéfinies

Tiré du dernier 66a0143a753cd4ade1a0fffee2174890d564c129, et il semble fonctionner correctement😎

Téléchargez toujours le binaire à plusieurs reprises.

• nœud v6.13.1
• fil v1.6.0-20180327.1507
• Système d'exploitation: Ubuntu 17.10 Linux 4.13.7-041307-generic
• ~ / .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

Le jeu.29 mars 2018 à 02h30, Andrew Lane [email protected]
a écrit:

Mise en cache locale des modules construits (à partir de # 5314
https://github.com/yarnpkg/yarn/pull/5314 ) peut vous aider ?:

Ajoutez .yarnrc à votre projet avec les éléments suivants:

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

Après la première installation, les modules préconstruits vivront dans
.// pré-construit. yarn.lock est également mis à jour
avec variantes pré-construites

Tiré le dernier 66a0143
https://github.com/yarnpkg/yarn/commit/66a0143a753cd4ade1a0fffee2174890d564c129 ,
et il semble fonctionner correctement😎

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/932#issuecomment-376989174 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAUAzz07Js-JQyj9n9_rsYq3cpd9Rp8qks5ti9a2gaJpZM4KVN87
.

@snowyu avez-vous supprimé yarn.lock, node_modules et yarn cache clean ? Est-ce que ./yarn-offline-mirror/prebuilt est renseigné après l'installation?

C'est un nouveau projet en temp. Oui, je peux voir le fichier node-sass-4.8.3.tgz dans le dossier cache.
Maintenant, je lance yarn cache clean . MAIS TOUJOURS télécharger le binaire à plusieurs reprises * .

`` bash

fil init -y
fil ajouter node-sass
fil ajouter v1.6.0-20180327.1507
info Aucun fichier de verrouillage trouvé.
[1/4] Résolution des packages ...
[2/4] Récupération des packages ...
[3/4] Lier les dépendances ...
[4/4] Construction de nouveaux paquets ... Téléchargement du binaire depuis https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
succès Fichier de verrouillage enregistré.
succès Sauvé 152 nouvelles dépendances.
Fait en 11,98s.

fil ajouter node-sass
fil ajouter v1.6.0-20180327.1507
[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 ... Téléchargement du binaire depuis https://github.com/sass/node-sass/releases/download/v4.8.3/linux-x64-57_binding.node
succès Fichier de verrouillage enregistré.
succès Sauvé 1 nouvelle dépendance.
info Dépendances directes
└─ [email protected]
info Toutes les dépendances
└─ [email protected]
Fait en 13 h 45.
''

OK, j'ai fait un simple repo git pour reproduire ce bogue.

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

yarn effectue une reconstruction inutile ttf2woff2 quand j'essaye d'ajouter une dépendance zéro 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 ... ]

Je peux reproduire cela dans le système OSX hôte et dans le conteneur Docker avec la dernière image node

NPM fonctionne correctement dans ce cas:

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 ... ]

Ma version de laine 1.5.1

@vlmonk est-ce que cela se produit toujours si vous clonez https://github.com/rally25rs/yarn à partir de @ rally25rs et utilisez le code dans # 5470 (branche fix-linking-rebuilding-uws-932 )?

@karlhorky oui, le fil est toujours reconstruit ttf2woff2 après avoir ajouté left-pad

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

Le package ttf2woff2 est fourni avec des fichiers qui ont été modifiés à l'étape de construction. Lors de la prochaine exécution, Yarn voit ces fichiers modifiés et réinstalle le package.

Yarn devrait mieux gérer cette situation: il devrait voir que ces fichiers ont changé pendant l'étape de construction et il devrait accepter ces fichiers modifiés comme les fichiers "corrects", et non pas les traiter comme une raison pour une réinstallation.

J'ai vérifié cela avec une journalisation supplémentaire (https://github.com/sth/yarn/tree/trace-rebuild). Lors de la première installation, il montre:

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

Le fichier de package https://registry.npmjs.org/ttf2woff2/-/ttf2woff2-2.0.3.tgz contient en effet ces fichiers.

Nous le voyons également avec OS X, l'ajout de tout package avec yarn add déclenche une recompilation de tous les packages dépendants. Nous avons un package node-gyp avec du code natif, cela prend plus d'une minute à chaque fois qu'un autre package est ajouté, et il n'y a pas encore beaucoup de code dans le module natif (ça va devenir bien pire). C'est avec le fil 1.5.1.

Nous utilisons yarn add ../a avec des chemins relatifs si cela fait une différence.

Veuillez me faire savoir s'il existe des solutions de contournement ou quand cela sera corrigé.

C'est avec le fil 1.5.1.

Ce problème a été résolu dans la version 1.6.0 qui est sortie assez récemment.

Je vois toujours cela avec 1.6. Depuis le passage de npm à yarn il y a longtemps uws comme toujours reconstruit (ou au moins yarn a été bloqué sur uws pour environ 5 à 10 secondes).

Étapes à suivre pour reproduire:

1. $ fil obsolète
2. choisissez un package obsolète
3. $ yarn upgrade [package]

@grantila pouvez-vous fournir un package.json complet ou un repo avec des étapes qui reproduisent cela avec Yarn 1.6.0 ?

cela se produit toujours sur 1.6.0

vous pouvez reproduire cela en utilisant ce https://github.com/yarnpkg/yarn/issues/932#issuecomment -377112784

J'ai un projet simple et je le vois aussi. L'ajout ou la suppression d'un package semble déclencher une reconstruction complète d'au moins un package à chaque fois.

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

Après leur installation, j'ai ajouté le package unescape , qui a déclenché une reconstruction de sodium . Ensuite, je l'ai supprimé, ce qui a déclenché une reconstruction de ce qui ressemblait à chaque paquet qui devait être compilé. L'ajout de ce package simple a pris 36s et sa suppression en 100s!

EDIT: en utilisant Node 8.11.1 et yarn 1.6.0 sur Debian Stretch.

@arcanis @ rally25rs veuillez rouvrir le problème, plusieurs rapports de cela se produisent encore, même avec le correctif fusionné.

Je pense que c'est plus un problème @ rally25rs :)

@grantila an upgrade va _toujours_ tout reconstruire. C'est intentionnel. npm fait la même chose (je le mentionne dans un commentaire quelque part dans ce long fil de discussion.) bien que nous puissions potentiellement essayer d'arrêter de le faire. Je ne suis pas sûr des répercussions que cela pourrait avoir.

Tous les autres:

Dans # 5680, je souligne que cela se produit toujours si un paquet supprime ses propres fichiers _ (pourquoi oh pourquoi font-ils ces choses 😿) _ et que le fil ne suit pas cela n'importe où (nous suivons quels fichiers sont créés ou modifiés), donc il pense simplement que le paquet n'a pas de fichiers et le reconstruit.

Je suppose que nous pouvons rouvrir cela, mais cela a été corrigé pour la plupart des paquets. Si quelqu'un veut ajouter "moi aussi" à ceci, _veuillez_ soit fournir votre package.json, soit mentionner spécifiquement quel paquet est en cours de reconstruction, car vous pouvez avoir des dépendances qui se reconstruisent et d'autres pas.

Tout le monde est le bienvenu pour faire un PR pour cela! (voir mes commentaires de débogage dans # 5680)

Désolé d'avoir ajouté plus de bruit, mais j'aimerais suggérer de verrouiller ce problème et de pointer vers un nouveau avec ces dernières informations en haut.

Je pense que le problème ici a beaucoup changé et qu'il est au moins partiellement résolu. Avec tous les messages ici, il est difficile pour quelqu'un de nouveau de se mettre au courant de ce qui a été corrigé et de ce qui reste un problème.

Je suis d'accord avec @ james-rabbit

Oui, tu as raison. Je vais verrouiller celui-ci pour que la réponse de @ rally25rs reste visible.

Si vous rencontrez un problème avec les packages natifs:

• Si cela se produit avec chaque dépendance native, veuillez ouvrir un problème générique. Ce problème aurait dû être résolu, donc je ne m'attends pas à en voir un de si tôt - cependant, si vous pouvez fournir des étapes de reproduction, n'hésitez pas à ouvrir un nouveau numéro (et vous pouvez créer un lien vers celui-ci si vous le souhaitez).

• Si cela se produit avec une dépendance native