Yarn: `yarn install --production` n'installe pas les dépendances correctes

Créé le 12 oct. 2016  ·  115Commentaires  ·  Source: yarnpkg/yarn

Lors de l'exécution de yarn install --production il n'installe pas les dépendances requises de forever . Cela semble être lié au fait d'avoir nodemon dans devDependencies .

Réponse d'erreur:

> forever app.js
module.js:457
    throw err;
    ^
Error: Cannot find module 'minimatch'

J'ai créé une application de test ici:
https://github.com/donovan-graham/yarn-example-app

#  Steps to reproduce error
git clone https://github.com/donovan-graham/yarn-example-app.git
cd yarn-example-app
yarn install --production
npm start

#  temporary step to bypass error
rm -rf node_modules
yarn remove nodemon
yarn install --production
npm start
cat-bug

Commentaire le plus utile

Salut tout le monde, désolé que vous rencontriez ce problème depuis un bon moment maintenant.
Je vais m'attribuer ce problème et c'est maintenant une priorité élevée, je vais essayer de le résoudre pendant les vacances.
L'aide et les PR avec des tests de rupture isolés ou un correctif (idéalement) sont les bienvenus.

Tous les 115 commentaires

@ Daniel15 Je suppose que c'est parce que nodemon a la dernière version de minimatch.

La fonction de l'éditeur de liens prend actuellement à la fois les déps et les déps. Pour la production d'arguments, cela doit être évité.

Même sur du fil normal, installez sans argument de production. Seule la dernière version est installée dans le chemin réel. Cela doit également être vérifié.

J'obtiens un problème similaire en exécutant yarn install --production , puis en essayant d'exécuter ma compilation en utilisant webpack (exécuter yarn install fonctionne bien).

> NODE_ENV=production webpack -p --config webpack/production.config.js

module.js:457
    throw err;
    ^

Error: Cannot find module 'graceful-fs'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)

et si je me souviens bien, les tentatives précédentes ont montré des erreurs similaires avec un autre paquet (pas seulement graceful-fs )

Je suis très similaire aussi ... yarn install fonctionne très bien. mais avec le drapeau --production j'obtiens ceci:

> yarn install --production

yarn install v0.15.1
error npm-shrinkwrap.json found. This will not be updated or respected. See [TODO] for more information.
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The engine "rhino" appears to be invalid.
warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
warning [email protected]: The engine "rhino" appears to be invalid.
warning [email protected]: The engine "rhino" appears to be invalid.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
[1/1] ⠐ node-sass:     at Module.require (module.js:367:17)
[-/1] ⠐ waiting...
[-/1] ⠐ waiting...
[-/1] ⠐ waiting...
error C:\vagrant\ebroker-quoteengine\node_modules\node-sass: Command failed.
Exit code: 1
Command: C:\WINDOWS\system32\cmd.exe
Arguments: /d /s /c node scripts/install.js
Directory: C:\vagrant\ebroker-quoteengine\node_modules\node-sass
Output:
module.js:341
    throw err;
    ^

Error: Cannot find module 'tough-cookie'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (C:\vagrant\ebroker-quoteengine\node_modules\node-sass\node_modules\request\lib\cookies.js:3:13)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at SpawnError (C:\Users\nathan.white\AppData\Roaming\npm\node_modules\yarnpkg\lib\errors.js:18:1)
    at ChildProcess.<anonymous> (C:\Users\nathan.white\AppData\Roaming\npm\node_modules\yarnpkg\lib\util\child.js:107:15)
    at emitTwo (events.js:100:13)
    at ChildProcess.emit (events.js:185:7)
    at maybeClose (internal/child_process.js:827:16)
    at Socket.<anonymous> (internal/child_process.js:319:11)
    at emitOne (events.js:90:13)
    at Socket.emit (events.js:182:7)
    at Pipe._onclose (net.js:471:12)

Peut reproduire un problème similaire avec:

npm init --yes
yarn add --dev nodemon
yarn add gulp
rm -rf node_modules
yarn install --production

Cela installera is-glob mais pas sa dépendance is-extglob :

> yarn why is-glob
yarn why v0.16.0
# ...
info Reasons this module exists
   - "nodemon#chokidar" depends on it
   - "gulp#liftoff#findup-sync" depends on it

> yarn why is-extglob
yarn why v0.16.0
#  ...
info This module exists because "nodemon#chokidar#is-glob" depends on it.

Il semble "oublier" le chemin de dépendance gulp#liftoff lors de la traversée ..?

EDIT: Exemple plus petit:

npm init --yes
yarn add --dev [email protected]
yarn add [email protected]
rm -rf node_modules
yarn --prod
node -e "require('is-glob')"

A également confirmé que la suppression de devDependencies avant d'exécuter yarn --prod installe l'arborescence de dépendances correcte.

Mon équipe logicielle a rencontré ce problème, en particulier avec le package prr qui est une dépendance de less et de pouchdb . De nombreux autres packages manquaient également dans la compilation --production mais prr été le premier à provoquer un échec de notre produit. Ce problème a été un grand succès pour nous, car la taille de notre programme d'installation augmenterait considérablement si nous incluions les packages de développement, nous sommes donc revenus à l'utilisation de npm.

FWIW: Je peux contourner le problème en supprimant la section devDependencies de package.json avant d'exécuter yarn en production.

comme @gihrig l'a dit, exécuter npm prune --production peut supprimer les devDependencies, ce qui permet de contourner ce problème.

comme @gihrig l'a dit, exécuter npm prune --production peut supprimer les devDependencies, ce qui permet de contourner ce problème.

Le principal avantage de Yarn par rapport à npm est un dir node_modules c'est-à-dire le même en dev, CI et la production prête à l'emploi. Exécuter npm prune --production produit-il le même comportement?

Ma solution de contournement actuelle consiste simplement à installer devDependencies en production également. Le disque est bon marché (en particulier sur AWS) et une installation déterministe est beaucoup plus importante pour moi que l'espace disque. Donc, ma "solution de contournement" consiste simplement à agir comme si yarn --production n'existe pas pour le moment.

@tanx npm prune --production supprimez simplement les devDependencies. Et dans mes tests, les mêmes modules ont toujours été supprimés. D'un autre côté, oui, l'espace disque est bon marché, alors peut-être agir comme si yarn --production ne sortait pas est une meilleure solution de contournement :)

@tanx npm prune --production supprime simplement les devDependencies. Et dans mes tests, les mêmes modules ont toujours été supprimés.

C'est précisément la mentalité "travaille sur ma machine" décrite dans le billet de blog Yarn . Le problème est que vous laissez npm changer l'état de node_modules sans vérification d'intégrité du fil via le fichier yarn.lock .

Espérons que les solutions de contournement discutées seront bientôt rendues inutiles par une mise à jour du fil pour respecter les déps de développement et de production. En attendant, il y a en effet beaucoup à gémir avec le hack de post-traitement "npm prune".

La chose yarn why décrite ci-dessus n'est pas liée. Cela semble être juste un effet secondaire de la façon dont le code why recherche les packages.

J'ai essayé de trouver un bon moyen de le faire sans ajouter de passe supplémentaire pour propager la visibilité après avoir parcouru le graphique une fois. Vous ne savez pas s'il serait acceptable de simplement diviser la visibilité en une étape distincte ..?

Il y a aussi des cas limites intéressants, il ne s'agit pas seulement de résoudre correctement la visibilité:

  • A est une dépendance facultative d'une dépendance de production
  • B est une dépendance non optionnelle d'une dépendance dev
  • C est une dépendance non facultative des deux

Dans ce cas, l'indicateur facultatif de C dépend de dev vs. prod. En dev, ce serait non optionnel, en prod, ce serait optionnel. Le simple fait d'hériter de l'indicateur facultatif de l'un des parents (ou de toujours l'hériter du parent prod) pourrait conduire à de l'étrangeté.

Ce n'est toujours pas corrigé dans la version 0.17.2 😢

Repro: https://gist.github.com/SimenB/2b179f3b6bca73ba824e1273ea38aed3

yarn

node index.js # works

yarn --prod

node index.js # explodes

/ cc @jkrems

Cela ne me semble pas fixe non plus dans la version 0.17.2 (HearthSim / Joust # 169).

Je vais le rouvrir car il peut être facilement reproduit avec les instructions de @SimenB .

@wyze Le problème pourrait être l'installation elle-même, et non l'élagage?

rm -rf node_modules/ && yarn && npm prune --production && node index.js échoue avec la même erreur.

rm -rf node_modules/ && npm i && npm prune --production && node index.js fonctionne cependant.

Je suppose que le fil et le npm ne sont pas destinés à être utilisés en même temps, donc cela pourrait être une coïncidence si cela produit la même erreur.

Différer node_modules après npm i et yarn montre que le fil ne produit pas "_requiredBy" , probablement pourquoi npm prune échoue après un yarn install . Cette information est cependant disponible dans le fichier de verrouillage, donc cela ne devrait pas être un problème, n'est-ce pas?

Même problème ici, nous testions le bâtiment de production sur docker et découvrions qu'avec yarn --production le paquet mime manquait même si le module parent send (utilisé par express) était installé .

Je pense que ce problème doit être traité avec une priorité maximale car cela cause des builds imprévisibles.

Pour contourner le problème, je supprime simplement la section devDependencies de package.json dans mon script de construction.

$ jq 'del(.devDependencies)' package.json > tmp.json && mv tmp.json package.json

Suite aux conseils de @ dy-dx, j'ai écrit un point d'entrée personnalisé pour Docker afin de résoudre ce problème pendant le développement:

Tout d'abord, vous devez installer jq dans votre Dockerfile en ajoutant cette ligne quelque part:

RUN apt-get update && \
    apt-get install -y jq

Ajoutez ensuite ce script quelque part et utilisez-le comme Dockerfile [ENTRYPOINT] ou docker-compose entrypoint entrypoint.sh

Utilisez votre commande préférée pour Dockerfile [CMD] ou docker-compose command Ex. npm start

Le même script pourrait être utilisé dans CI avec quelques modifications pour créer l'image

@SimenB Pouvez-vous retirer le node_modules de votre forfait entries-test et essayer?

https://registry.yarnpkg.com/entries-test/-/entries-test-1.0.1.tgz#1bf192e414ceadd0cf4b77b3969df32de2985d50

Extrayez la balle tar v1.0.1, il y a un dossier node_modules avec define-properties et d'autres modules. Et aucun d'entre eux n'a *.js fichier

@torifat Huh, comment ça s'est passé? Il ne devrait pas être possible d'inclure un node_modules sans utiliser bundledDependencies ...
Je vais essayer d'en pousser un propre (j'ai supprimé les projets, je devrai recréer).

@torifat C'est la faute du fil, ça ressemble.

$ mkdir some-dir && cd some-dir && yarn init -y && yarn add object.entries && yarn pack && tar -ztvf some-dir-v1.0.0.tgz
drwxr-xr-x  0 0      0           0 Nov 27 10:36 package
-rw-r--r--  0 0      0         972 Oct 15  2015 package/node_modules/define-properties/CHANGELOG.md
-rw-r--r--  0 0      0        1080 Oct 15  2015 package/node_modules/define-properties/LICENSE
-rw-r--r--  0 0      0        2725 Oct 15  2015 package/node_modules/define-properties/README.md
-rw-r--r--  0 0      0        1593 Oct 15  2015 package/node_modules/define-properties/package.json
-rw-r--r--  0 0      0        3798 Aug 21 11:09 package/node_modules/es-abstract/CHANGELOG.md
-rw-r--r--  0 0      0        1080 Jul 29  2015 package/node_modules/es-abstract/LICENSE
-rw-r--r--  0 0      0        1812 Aug 13  2015 package/node_modules/es-abstract/README.md
-rw-r--r--  0 0      0        1989 Aug 21 11:09 package/node_modules/es-abstract/package.json
-rw-r--r--  0 0      0        1207 Jan  4  2016 package/node_modules/es-to-primitive/CHANGELOG.md
-rw-r--r--  0 0      0        1082 Nov  1  2015 package/node_modules/es-to-primitive/LICENSE
-rw-r--r--  0 0      0        2180 Nov  1  2015 package/node_modules/es-to-primitive/README.md
-rw-r--r--  0 0      0        1558 Jan  4  2016 package/node_modules/es-to-primitive/package.json
-rw-r--r--  0 0      0        1074 Sep 22  2014 package/node_modules/foreach/LICENSE
-rw-r--r--  0 0      0         593 Sep 22  2014 package/node_modules/foreach/Readme.md
-rw-r--r--  0 0      0        1297 Sep 22  2014 package/node_modules/foreach/package.json
-rw-r--r--  0 0      0        1052 Feb 14  2016 package/node_modules/function-bind/LICENSE
-rw-r--r--  0 0      0        1488 Feb 14  2016 package/node_modules/function-bind/README.md
-rw-r--r--  0 0      0        1619 Feb 14  2016 package/node_modules/function-bind/package.json
-rw-r--r--  0 0      0        1060 Jul 24  2015 package/node_modules/has/LICENSE-MIT
-rw-r--r--  0 0      0         239 Jul 24  2015 package/node_modules/has/README.mkd
-rw-r--r--  0 0      0         782 Jul 24  2015 package/node_modules/has/package.json
-rw-r--r--  0 0      0        1839 Feb 28  2016 package/node_modules/is-callable/CHANGELOG.md
-rw-r--r--  0 0      0        1082 May 19  2015 package/node_modules/is-callable/LICENSE
-rw-r--r--  0 0      0        1978 Aug 12  2015 package/node_modules/is-callable/README.md
-rw-r--r--  0 0      0        1983 Feb 28  2016 package/node_modules/is-callable/package.json
-rw-r--r--  0 0      0         421 Sep 27  2015 package/node_modules/is-date-object/CHANGELOG.md
-rw-r--r--  0 0      0        1082 Mar 13  2015 package/node_modules/is-date-object/LICENSE
-rw-r--r--  0 0      0        1751 Aug 12  2015 package/node_modules/is-date-object/README.md
-rw-r--r--  0 0      0        1420 Sep 27  2015 package/node_modules/is-date-object/package.json
-rw-r--r--  0 0      0         482 Jan 30  2015 package/node_modules/is-regex/CHANGELOG.md
-rw-r--r--  0 0      0        1081 Jan 15  2014 package/node_modules/is-regex/LICENSE
-rw-r--r--  0 0      0        1623 Jan 28  2015 package/node_modules/is-regex/README.md
-rw-r--r--  0 0      0        1512 Jan 30  2015 package/node_modules/is-regex/package.json
-rw-r--r--  0 0      0         121 Jan 26  2015 package/node_modules/is-symbol/CHANGELOG.md
-rw-r--r--  0 0      0        1082 Jan 24  2015 package/node_modules/is-symbol/LICENSE
-rw-r--r--  0 0      0        1469 Jan 24  2015 package/node_modules/is-symbol/README.md
-rw-r--r--  0 0      0        1214 Jan 26  2015 package/node_modules/is-symbol/package.json
-rw-r--r--  0 0      0        6992 Jul  5 19:14 package/node_modules/object-keys/CHANGELOG.md
-rw-r--r--  0 0      0        1080 Oct 15  2015 package/node_modules/object-keys/LICENSE
-rw-r--r--  0 0      0        2460 Oct 15  2015 package/node_modules/object-keys/README.md
-rw-r--r--  0 0      0        1955 Jul  5 19:14 package/node_modules/object-keys/package.json
-rw-r--r--  0 0      0         560 Oct  6  2015 package/node_modules/object.entries/CHANGELOG.md
-rw-r--r--  0 0      0        1082 Sep  2  2015 package/node_modules/object.entries/LICENSE
-rw-r--r--  0 0      0        2339 Sep  2  2015 package/node_modules/object.entries/README.md
-rw-r--r--  0 0      0        1636 Oct  6  2015 package/node_modules/object.entries/package.json
-rw-r--r--  0 0      0         145 Nov 27 10:36 package/package.json

L'utilisation de npm pack fonctionne comme prévu (dans le même répertoire).

$ npm pack && tar -ztvf some-dir-1.0.0.tgz
-rw-r--r--  0 501    20        145 Nov 27 10:36 package/package.json
-rw-r--r--  0 501    20       2460 Nov 27 10:36 package/yarn.lock

On dirait que Yarn est tellement déterminé à inclure changelog , readme et package.json qu'il les inclut même à partir de node_modules ...

Utilisation de [email protected]

@torifat Published 1.0.2 maintenant (en utilisant npm pour éviter le bogue qui vient d'être mentionné), toujours le même problème

Ouvert # 2047 pour le bogue concernant node_modules, mais c'est un hareng rouge dans ce numéro, car ma repro est toujours valide avec une archive tar appropriée publiée.

(désolé pour le spam aux abonnés, je vais m'arrêter maintenant)

@SimenB Merci pour votre temps. J'ai découvert le bug.

Cela semble être lié à # 2104, que je viens d'ouvrir. Le node_modules/.bin après l'installation de l'OP:

$ ll node_modules/.bin
total 16
lrwxr-xr-x  1 samuelreed  staff    22B Dec  1 11:16 forever -> ../forever/bin/forever
lrwxr-xr-x  1 samuelreed  staff   109B Dec  1 11:16 nodemon -> ../../../../../Library/Caches/Yarn/npm-nodemon-1.11.0-226c562bd2a7b13d3d7518b49ad4828a3623d06c/bin/nodemon.js

Corrigé via # 2116.

Le # 2116 a-t-il déjà été fusionné? Je ne peux pas le voir dans l'historique des commit. Il semble prématuré de fermer un certain nombre de problèmes avant qu'un correctif ne soit disponible, au moins sur master sinon dans une version balisée. De plus, il semble que # 2116 échoue aux trois vérifications. Est-ce que je manque quelque chose?

C'est toujours un problème dans la v0.18.0, qui inclut (# 2116).

oui, je peux confirmer que ce problème est toujours présent dans la version 0.18.0

D'après ce que je vois, le # 2116 aurait dû introduire des tests pour ce problème ( test.concurrent ('- l'indicateur de production ignore les dépendances de développement' ... ou je me trompe?

Le test ne vérifie pas le comportement correct des dépendances transitives:
Dans mon cas, le problème est une dépendance partagée (lru-cache) entre une dépendance prod (minimatch v2.0.0) et une dépendance dev (useragent v2.1.9). Cette dépendance partagée n'est pas installée dans --production , même si la dépendance prod l'exige.

@beheh Je ne vois pas si minimatch utilise lru-cache , c'est peut-être pour cela qu'il n'est pas installé en production?

Je fais des tests avec 0.18.0

dep { A->B }
devDep { B }
OK
A,B are installed.
dep { A->C->D }
devDep { B->C->D }
OK
A,C,D are installed.
dep { E->A->C->D }
devDep { B->C->D }
KO
E,A,C are installed but D is missing.

c'est le cas illustré par @SimenB

"dependencies": {
    "entries-test": "^1.0.1"
  },
  "devDependencies": {
    "object.values": "^1.0.3"
  }

@SharpEdgeMarshall Merci pour les tests. Je vais l'ajouter comme cas de test.

@torifat pourrait également envisager de le rouvrir

@SharpEdgeMarshall J'ai essayé ce qui suit et ça marche. Besoin de comprendre le problème réel.

screenshot 2016-12-06 21 18 44

@SimenB doit vérifier avant de rouvrir. Cela peut également arriver en raison de optionalDependencies . Ce qui a un autre problème ouvert.

@torifat mon repro se produit toujours: https://github.com/yarnpkg/yarn/issues/761#issuecomment -260975012

EDIT: qui n'a pas de deps optionnel, grep optional yarn.lock sort avec 1

Il échoue maintenant sur Error: Cannot find module 'object-keys' au lieu de manquer define-properties .

$ yarn why object-keys
yarn why v0.18.0
[1/4] 🤔  Why do we have the module "object-keys"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
info This module exists because "object.values#define-properties" depends on it.
✨  Done in 0.09s.

On dirait qu'il gère maintenant un niveau plus profond, mais échoue ensuite

@SimenB Je

{
  "dependencies": {
    "entries-test": "^1.0.1"
  },
  "devDependencies": {
    "object.values": "^1.0.3"
  }
}

Et ça marche bien pour moi. Pouvez-vous faire un yarn cache clean et réessayer?

Non, échoue

@SimenB Pouvez-vous partager votre fichier yarn.lock ?

$ rm -rf node_modules && rm yarn.lock && yarn cache clean && yarn && node index.js && yarn --prod && node index.js
yarn cache v0.18.0
success Cleared cache.
✨  Done in 0.07s.
yarn install v0.18.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 0.92s.
yarn install v0.18.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 0.18s.
module.js:471
    throw err;
    ^

Error: Cannot find module 'object-keys'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/simbekkh/repos/ugh/node_modules/define-properties/index.js:3:12)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

Pour moi, l'exemple de SimenB ne fonctionne pas avec 0.18.0 même après yarn cache clean

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


define-properties@^1.1.2:
  version "1.1.2"
  resolved "http://npm.office.crweb.it/define-properties/-/define-properties-1.1.2.tgz#83a73f2fea569898fb737193c8f873caf6d45c94"
  dependencies:
    foreach "^2.0.5"
    object-keys "^1.0.8"

entries-test@^1.0.1:
  version "1.0.2"
  resolved "http://npm.office.crweb.it/entries-test/-/entries-test-1.0.2.tgz#f1039aba3a2effc9c3a56b6b1180694b2789e4d5"
  dependencies:
    object.entries "^1.0.3"

es-abstract@^1.6.1:
  version "1.6.1"
  resolved "http://npm.office.crweb.it/es-abstract/-/es-abstract-1.6.1.tgz#bb8a2064120abcf928a086ea3d9043114285ec99"
  dependencies:
    es-to-primitive "^1.1.1"
    function-bind "^1.1.0"
    is-callable "^1.1.3"
    is-regex "^1.0.3"

es-to-primitive@^1.1.1:
  version "1.1.1"
  resolved "http://npm.office.crweb.it/es-to-primitive/-/es-to-primitive-1.1.1.tgz#45355248a88979034b6792e19bb81f2b7975dd0d"
  dependencies:
    is-callable "^1.1.1"
    is-date-object "^1.0.1"
    is-symbol "^1.0.1"

foreach@^2.0.5:
  version "2.0.5"
  resolved "http://npm.office.crweb.it/foreach/-/foreach-2.0.5.tgz#0bee005018aeb260d0a3af3ae658dd0136ec1b99"

function-bind@^1.0.2, function-bind@^1.1.0:
  version "1.1.0"
  resolved "http://npm.office.crweb.it/function-bind/-/function-bind-1.1.0.tgz#16176714c801798e4e8f2cf7f7529467bb4a5771"

has@^1.0.1:
  version "1.0.1"
  resolved "http://npm.office.crweb.it/has/-/has-1.0.1.tgz#8461733f538b0837c9361e39a9ab9e9704dc2f28"
  dependencies:
    function-bind "^1.0.2"

is-callable@^1.1.1, is-callable@^1.1.3:
  version "1.1.3"
  resolved "http://npm.office.crweb.it/is-callable/-/is-callable-1.1.3.tgz#86eb75392805ddc33af71c92a0eedf74ee7604b2"

is-date-object@^1.0.1:
  version "1.0.1"
  resolved "http://npm.office.crweb.it/is-date-object/-/is-date-object-1.0.1.tgz#9aa20eb6aeebbff77fbd33e74ca01b33581d3a16"

is-regex@^1.0.3:
  version "1.0.3"
  resolved "http://npm.office.crweb.it/is-regex/-/is-regex-1.0.3.tgz#0d55182bddf9f2fde278220aec3a75642c908637"

is-symbol@^1.0.1:
  version "1.0.1"
  resolved "http://npm.office.crweb.it/is-symbol/-/is-symbol-1.0.1.tgz#3cc59f00025194b6ab2e38dbae6689256b660572"

object-keys@^1.0.8:
  version "1.0.11"
  resolved "http://npm.office.crweb.it/object-keys/-/object-keys-1.0.11.tgz#c54601778ad560f1142ce0e01bcca8b56d13426d"

object.entries@^1.0.3:
  version "1.0.4"
  resolved "http://npm.office.crweb.it/object.entries/-/object.entries-1.0.4.tgz#1bf9a4dd2288f5b33f3a993d257661f05d161a5f"
  dependencies:
    define-properties "^1.1.2"
    es-abstract "^1.6.1"
    function-bind "^1.1.0"
    has "^1.0.1"

object.values@^1.0.3:
  version "1.0.4"
  resolved "http://npm.office.crweb.it/object.values/-/object.values-1.0.4.tgz#e524da09b4f66ff05df457546ec72ac99f13069a"
  dependencies:
    define-properties "^1.1.2"
    es-abstract "^1.6.1"
    function-bind "^1.1.0"
    has "^1.0.1"
$ rm -rf node_modules && rm yarn.lock && yarn cache clean && yarn && node index.js && rm -rf node_modules && rm yarn.lock && yarn cache clean && yarn --prod && node index.js
yarn cache v0.18.0
success Cleared cache.
✨  Done in 0.07s.
yarn install v0.18.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 0.93s.
yarn cache v0.18.0
success Cleared cache.
✨  Done in 0.07s.
yarn install v0.18.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 0.76s.
module.js:471
    throw err;
    ^

Error: Cannot find module 'object-keys'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/simbekkh/repos/ugh/node_modules/define-properties/index.js:3:12)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

Lockfile:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


define-properties@^1.1.2:
  version "1.1.2"
  resolved "https://registry.yarnpkg.com/define-properties/-/define-properties-1.1.2.tgz#83a73f2fea569898fb737193c8f873caf6d45c94"
  dependencies:
    foreach "^2.0.5"
    object-keys "^1.0.8"

entries-test@^1.0.1:
  version "1.0.2"
  resolved "https://registry.yarnpkg.com/entries-test/-/entries-test-1.0.2.tgz#f1039aba3a2effc9c3a56b6b1180694b2789e4d5"
  dependencies:
    object.entries "^1.0.3"

es-abstract@^1.6.1:
  version "1.6.1"
  resolved "https://registry.yarnpkg.com/es-abstract/-/es-abstract-1.6.1.tgz#bb8a2064120abcf928a086ea3d9043114285ec99"
  dependencies:
    es-to-primitive "^1.1.1"
    function-bind "^1.1.0"
    is-callable "^1.1.3"
    is-regex "^1.0.3"

es-to-primitive@^1.1.1:
  version "1.1.1"
  resolved "https://registry.yarnpkg.com/es-to-primitive/-/es-to-primitive-1.1.1.tgz#45355248a88979034b6792e19bb81f2b7975dd0d"
  dependencies:
    is-callable "^1.1.1"
    is-date-object "^1.0.1"
    is-symbol "^1.0.1"

foreach@^2.0.5:
  version "2.0.5"
  resolved "https://registry.yarnpkg.com/foreach/-/foreach-2.0.5.tgz#0bee005018aeb260d0a3af3ae658dd0136ec1b99"

function-bind@^1.0.2, function-bind@^1.1.0:
  version "1.1.0"
  resolved "https://registry.yarnpkg.com/function-bind/-/function-bind-1.1.0.tgz#16176714c801798e4e8f2cf7f7529467bb4a5771"

has@^1.0.1:
  version "1.0.1"
  resolved "https://registry.yarnpkg.com/has/-/has-1.0.1.tgz#8461733f538b0837c9361e39a9ab9e9704dc2f28"
  dependencies:
    function-bind "^1.0.2"

is-callable@^1.1.1, is-callable@^1.1.3:
  version "1.1.3"
  resolved "https://registry.yarnpkg.com/is-callable/-/is-callable-1.1.3.tgz#86eb75392805ddc33af71c92a0eedf74ee7604b2"

is-date-object@^1.0.1:
  version "1.0.1"
  resolved "https://registry.yarnpkg.com/is-date-object/-/is-date-object-1.0.1.tgz#9aa20eb6aeebbff77fbd33e74ca01b33581d3a16"

is-regex@^1.0.3:
  version "1.0.3"
  resolved "https://registry.yarnpkg.com/is-regex/-/is-regex-1.0.3.tgz#0d55182bddf9f2fde278220aec3a75642c908637"

is-symbol@^1.0.1:
  version "1.0.1"
  resolved "https://registry.yarnpkg.com/is-symbol/-/is-symbol-1.0.1.tgz#3cc59f00025194b6ab2e38dbae6689256b660572"

object-keys@^1.0.8:
  version "1.0.11"
  resolved "https://registry.yarnpkg.com/object-keys/-/object-keys-1.0.11.tgz#c54601778ad560f1142ce0e01bcca8b56d13426d"

object.entries@^1.0.3:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/object.entries/-/object.entries-1.0.4.tgz#1bf9a4dd2288f5b33f3a993d257661f05d161a5f"
  dependencies:
    define-properties "^1.1.2"
    es-abstract "^1.6.1"
    function-bind "^1.1.0"
    has "^1.0.1"

object.values@^1.0.3:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/object.values/-/object.values-1.0.4.tgz#e524da09b4f66ff05df457546ec72ac99f13069a"
  dependencies:
    define-properties "^1.1.2"
    es-abstract "^1.6.1"
    function-bind "^1.1.0"
    has "^1.0.1"

@SimenB Merci. Il semble que mon cache avait un problème. Après avoir vidé mon cache maintenant, il échoue. Mais, avec une erreur différente. Donnez-moi un peu de temps pour enquêter.

Btw, je recommande d'utiliser https://github.com/Mottie/Octopatcher dans ce fil

Très pratique avec de nombreuses lignes de sortie

image

Je vais arrêter de spammer maintenant

@SimenB Échec dans v0.18.0 mais ne peut pas se reproduire dans le dernier master .

MISE À JOUR: Bizarre! Il échoue à nouveau 😕

@torifat je peux confirmer que cela ne fonctionne pas avec master (v0.19.0)
rm -rf node_modules && rm yarn.lock && ../yarn/bin/yarn cache clean && ../yarn/bin/yarn && node index.js && rm -rf node_modules && rm yarn.lock && ../yarn/bin/yarn cache clean && ../yarn/bin/yarn --prod && node index.js

yarn cache v0.19.0-0
success Cleared cache.
Done in 0.58s.
yarn install v0.19.0-0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 10.18s.
yarn cache v0.19.0-0
success Cleared cache.
Done in 0.09s.
yarn install v0.19.0-0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 4.26s.
module.js:457
    throw err;
    ^

Error: Cannot find module 'object-keys'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/sharpedge/git/Utility/YarnBug/node_modules/define-properties/index.js:3:12)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)

J'ai les mêmes problèmes (certains paquets ne sont pas installés avec le drapeau --production ) avec le stable actuel 0.17.10 :

curl -o- -L https://yarnpkg.com/install.sh | bash && ~/.yarn/bin/yarn install --production && rm -rf ~/.yarn

Mais lorsque j'essaye la version nocturne actuelle Yarn 0.19.0-20161207.1241 tous les packages nécessaires ont été installés correctement pour mon application:

wget https://yarnpkg.com/install.sh && chmod +x install.sh && ./install.sh --nightly && rm -f install.sh && ~/.yarn/bin/yarn install --production && rm -rf ~/.yarn

@SharpEdgeMarshall @SimenB pouvez-vous essayer la dernière version nocturne et confirmer que le problème persiste.

Utilisé dans mes conteneurs docker: https://gist.github.com/nodkz/b843d65a3430a4f510e5f5eb0cc759d2

@nodkz 18 est sorti et stable (je pense?), mais comme on peut le voir dans le post directement au-dessus du vôtre, master (il y a au moins 2 jours) a toujours le bogue

Je pense que cela nécessite toujours install yarn@rc :

'dist-tags': { rc: '0.18.0', latest: '0.17.10' },

C'est nouveau alors, j'ai obtenu 0.18 il y a quelques jours en installant simplement. Quoi qu'il en soit, le bogue est toujours reproductible en 0.18.

@nodkz Repro c'est:

{
  "dependencies": {
    "entries-test": "^1.0.1"
  },
  "devDependencies": {
    "object.values": "^1.0.3"
  }
}

Oui, rencontrant également des problèmes similaires avec nos projets:

rm -rf package.json yarn.lock node_modules && npm init --yes && yarn add --dev nodemon && yarn add glob-stream && yarn --prod && node -p "require('glob-stream')"

Échoue avec la version 0.18 et la dernière branche principale.

D'accord. Toujours capable de repro avec le dernier.

Je pense que mon problème est similaire ou identique à celui-ci. La construction échoue sur Heroku, mais uniquement pour l'environnement de production. La mise en cache est désactivée.

Resolving node version ^7.2.1 via semver.io...
       Downloading and installing node 7.2.1...
       Using default npm version: 3.10.10
       Resolving yarn version (latest) via semver.io...
       Downloading and installing yarn (0.18.1)...
       Installed yarn 0.18.1
-----> Restoring cache
       Skipping cache restore (disabled by config)
-----> Building dependencies
       Installing node modules (yarn)
       yarn install v0.18.1
       [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...
       error /tmp/build_0e4ff736ad0f25dc816a47543687fefc/bbb7b6e751dde291f65dea175f41a26862eef28f/node_modules/bcrypt: Command failed.
       Exit code: 1
       Command: sh
       Arguments: -c node-pre-gyp install --fallback-to-build
       Directory: /tmp/build_0e4ff736ad0f25dc816a47543687fefc/bbb7b6e751dde291f65dea175f41a26862eef28f/node_modules/bcrypt
       Output:
       module.js:472
       throw err;
       ^

       Error: Cannot find module 'abbrev'
       at Function.Module._resolveFilename (module.js:470:15)
       at Function.Module._load (module.js:418:25)
       at Module.require (module.js:498:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_0e4ff736ad0f25dc816a47543687fefc/bbb7b6e751dde291f65dea175f41a26862eef28f/node_modules/nopt/lib/nopt.js:10:14)
       at Module._compile (module.js:571:32)
       at Object.Module._extensions..js (module.js:580:10)
       at Module.load (module.js:488:32)
       at tryModuleLoad (module.js:447:12)
       at Function.Module._load (module.js:439:3)
       info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
-----> Build failed

J'ai aussi ce problème. J'utilise toujours yarn install pour la production à partir du moment car yarn install --production n'installe pas correctement les bonnes dépendances.

J'ai peur de ne pas pouvoir le faire, car il est codé en dur à yarn install --production dans le buildpack Heroku, je pense (ref https://github.com/heroku/heroku-buildpack-nodejs/issues/337)

@adamreisnz Désolé, je faisais référence au problème d'origine, pas au vôtre.

Pour résoudre votre problème, je vous suggère de mettre tous les devDependencies à dependencies pour le moment jusqu'à ce que ce problème soit résolu.

@dashmug Ah ok, pas de problème.

Quoi qu'il en soit, je préfère utiliser npm sur Heroku pour l'instant jusqu'à ce que Yarn soit plus stable, plutôt que de se débrouiller avec des solutions hacky. J'ai mis yarn.lock dans mon .gitignore pour qu'il ne soit pas téléchargé dans le repo / heroku. De cette façon, je peux toujours utiliser Yarn localement, mais cela n'affectera pas les builds sur Heroku.

@adamreisnz Cela va à l' yarn , vous ne pensez pas?

@dashmug Pas vraiment, du moins, pas pour nous. Je ne l'utilise pas pour verrouiller les versions de package en place. Nous avons des dépendances très à jour et aucun problème concernant "fonctionne sur ma machine". Ma principale raison de passer à jarn over npm était la vitesse, qui pour les applications complexes avec beaucoup de dépendances, j'ai vu passer de 5 minutes pour un npm install à 22 secondes avec du fil.

Tant que le fil est instable, je peux vivre avec un processus de construction légèrement plus lent sur Heroku, tant que je peux utiliser du fil localement pour le développement et avoir des installations rapides :)

Yarn est annoncé comme étant à peu près un remplacement direct pour npm. Cependant, certains des problèmes que nous avons rencontrés et qui ne sont toujours pas résolus, comme celui-ci, nous empêchent de l'utiliser comme tel. C'est pourquoi je le vois actuellement comme un outil supplémentaire, utile pour une chose, mais pas encore là pour une autre. Je n'ai aucun doute avec le temps que cela fonctionnera très bien :)

Cela semble être résolu pour moi dans la version 0.18.1.

Heroku utilisait 0.18.1 au moment où il a échoué, donc pas encore corrigé.

Ce problème est résolu pour moi sur 0.18.1.

Ma précédente repro est corrigée avec 0.18.1 🎉

J'essaierai demain avec une vraie application

0.18.1 résout mes problèmes. Je suis un campeur heureux 🎉

J'ai essayé la version 0.18.1 avec une application non triviale qui échouait auparavant et qui semble fonctionner maintenant! 🎉

Je suppose que je vais bientôt essayer :)

Désolé, ne fonctionne toujours pas avec 0.18.1;

-----> Node.js app detected
-----> Creating runtime environment

       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=true
       NODE_ENV=production
       NODE_MODULES_CACHE=true
-----> Installing binaries
       engines.node (package.json):  ^7.2.1
       engines.npm (package.json):   unspecified (use default)

       Resolving node version ^7.2.1 via semver.io...
       Downloading and installing node 7.2.1...
       Using default npm version: 3.10.10
       Resolving yarn version (latest) via semver.io...
       Downloading and installing yarn (0.18.1)...
       Installed yarn 0.18.1
-----> Restoring cache
       Loading 2 from cacheDirectories (default):
       - node_modules
       - bower_components (not cached - skipping)
-----> Building dependencies
       Installing node modules (yarn)
       yarn install v0.18.1
       [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...
       error /tmp/build_c86802dccae94b3fb074d3b88f3f63f2/9512deeed23c0eca48d68fb2c8850a28f76692ea/node_modules/bcrypt: Command failed.
       Exit code: 1
       Command: sh
       Arguments: -c node-pre-gyp install --fallback-to-build
       Directory: /tmp/build_c86802dccae94b3fb074d3b88f3f63f2/9512deeed23c0eca48d68fb2c8850a28f76692ea/node_modules/bcrypt
       Output:
       module.js:472
       throw err;
       ^

       Error: Cannot find module 'abbrev'
       at Function.Module._resolveFilename (module.js:470:15)
       at Function.Module._load (module.js:418:25)
       at Module.require (module.js:498:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_c86802dccae94b3fb074d3b88f3f63f2/9512deeed23c0eca48d68fb2c8850a28f76692ea/node_modules/nopt/lib/nopt.js:10:14)
       at Module._compile (module.js:571:32)
       at Object.Module._extensions..js (module.js:580:10)
       at Module.load (module.js:488:32)
       at tryModuleLoad (module.js:447:12)
       at Function.Module._load (module.js:439:3)
       info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
-----> Build failed

       We're sorry this build is failing! You can troubleshoot common issues here:
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys

       Some possible problems:

       - A module may be missing from 'dependencies' in package.json
       https://devcenter.heroku.com/articles/troubleshooting-node-deploys#ensure-you-aren-t-relying-on-untracked-dependencies

       - This module may be specified in 'devDependencies' instead of 'dependencies'
       https://devcenter.heroku.com/articles/nodejs-support#devdependencies

       Love,
       Heroku

 !     Push rejected, failed to compile Node.js app.
 !     Push failed

La configuration de NODE_MODULES_CACHE=false n'a pas non plus aidé.

Voici l'arborescence des dépendances:

├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └─┬ [email protected]
│       └─┬ [email protected]
│         └── [email protected] 
├─┬ [email protected]
│ └─┬ @google-cloud/[email protected]
│   └─┬ @google-cloud/[email protected]
│     └─┬ [email protected]
│       └─┬ [email protected]
│         └─┬ [email protected]
│           └── [email protected] 
└─┬ [email protected]
  └── [email protected] 

Je pense que le problème est la profonde dépendance via google-cloud . C'est un module de production, et bable-cli et instanbul sont uniquement des développeurs.

De plus, lorsque j'utilise yarn why abbrev , il ne parvient pas à récupérer les parents à charge google-cloud et babel-cli :

yarn why v0.18.1
[1/4] 🤔  Why do we have the module "abbrev"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
info Reasons this module exists
   - "istanbul" depends on it
   - "istanbul#nopt" depends on it

@jkrems , @SimenB Dois-je soulever un nouveau problème à ce sujet ou pas?

istanbul#nopt semble également faux, dans la sortie why .
Je suis sur ma façon de travailler maintenant, je vais tester dans une vraie application alors

@SimenB merci, faites-moi savoir si vous avez besoin de plus d'informations, par exemple toute ma liste de modules package.json.

Edit: en fait ici c'est juste au cas où, car je vais dormir maintenant;

"dependencies": {
    "bcrypt": "^1.0.1",
    "bluebird": "^3.4.6",
    "body-parser": "^1.15.2",
    "chalk": "^1.1.3",
    "compression": "^1.6.2",
    "cookie-parser": "^1.4.3",
    "cors": "^2.8.1",
    "express": "^4.14.0",
    "glob": "^7.1.1",
    "google-cloud": "^0.45.1",
    "handlebars": "^4.0.6",
    "html-pdf": "^2.1.0",
    "http-as-promised": "^1.1.0",
    "meanie-express-error-handling": "git+https://github.com/meanie/express-error-handling#2.0.0",
    "meanie-express-github-service": "^2.0.2",
    "meanie-express-jwt-service": "^1.0.2",
    "meanie-express-raven-service": "^1.0.1",
    "meanie-mail-composer": "^1.2.0",
    "meanie-mongoose-only-id": "^1.0.1",
    "meanie-mongoose-set-properties": "^1.0.1",
    "meanie-mongoose-to-json": "^1.1.0",
    "meanie-multer-mime-types-filter": "^1.0.1",
    "meanie-passport-refresh-strategy": "^1.1.2",
    "moment": "^2.17.1",
    "mongoose": "^4.7.3",
    "morgan": "^1.7.0",
    "multer": "^1.1.0",
    "passport": "^0.3.2",
    "passport-http-bearer": "^1.0.1",
    "passport-local": "^1.0.0",
    "phantomjs-prebuilt": "2.1.14",
    "sendgrid": "^4.7.1",
    "sendgrid-mailer": "^1.0.7",
    "socket.io": "^1.7.2",
    "yargs": "^6.5.0"
  },
  "devDependencies": {
    "babel-cli": "^6.16.0",
    "babel-preset-es2015": "^6.18.0",
    "chai": "^3.5.0",
    "chai-as-promised": "^6.0.0",
    "dirty-chai": "^1.2.2",
    "eslint": "^3.12.1",
    "express-simulate-latency": "0.0.2",
    "istanbul": "^1.0.0-alpha.2",
    "mocha": "^3.2.0",
    "mocha-clean": "^1.0.0",
    "nodemon": "^1.11.0",
    "sinon": "^1.17.6",
    "sinon-as-promised": "^4.0.0",
    "sinon-mongoose": "^1.3.0"
  }

Cela échoue toujours pour l'application au travail. On dirait que Yarn est incapable de suivre des chemins profonds. Voici npm ls entities après yarn --prod

$ npm ls entities
[email protected] /Users/simbekkh/repos/frontpage
└─┬ @finn-no/[email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └─┬ [email protected]
        └─┬ [email protected]
          └─┬ [email protected]
            └── UNMET DEPENDENCY entities@~1.1.1

npm ERR! missing: entities@~1.1.1, required by [email protected]

Identique à @adamreisnz , yarn why ne prend pas l'arbre correct.

$ yarn why entities
yarn why v0.18.1
[1/4] 🤔  Why do we have the module "entities"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
info Reasons this module exists
   - "cheerio" depends on it
   - "cheerio#htmlparser2" depends on it
info Disk size without dependencies: "108kB"
info Disk size with unique dependencies: "108kB"
info Disk size with transitive dependencies: "108kB"
info Amount of shared dependencies: 0
✨  Done in 0.40s.

istanbul # nopt semble également faux, dans la sortie pourquoi.

Vous avez raison, cela semble être au cœur de ce problème. Il semble penser que nopt fait partie du package istanbul , au lieu de google-cloud et / ou babel-cli , et c'est peut-être pourquoi il ne l'installe pas pour la production environnements, car istanbul n'est pas une dépendance prod.

Salut tout le monde, désolé que vous rencontriez ce problème depuis un bon moment maintenant.
Je vais m'attribuer ce problème et c'est maintenant une priorité élevée, je vais essayer de le résoudre pendant les vacances.
L'aide et les PR avec des tests de rupture isolés ou un correctif (idéalement) sont les bienvenus.

Nous avons le même problème dans prod env avec la lib bl qui est une dépendance des dépendances optionnelles de gulp-imagemin 😕

[~/Workspaces/my-project 12:05:33] NODE_ENV=production yarn
yarn install v0.18.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
warning algoliasearch > [email protected]: Just use Array.isArray directly
warning gulp-file > through2 > xtend > [email protected]:
warning raven > [email protected]: use uuid module instead
warning wiredep > bower-config > [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
warning chromedriver > [email protected]: this package has been reintegrated into npm and is now out of date with respect to npm
warning mversion > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning wiredep > glob > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning webdriverio > request > [email protected]: use uuid module instead
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected]: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
warning sprity-lwip > lwip > decree > [email protected]: This package is discontinued. Use lodash@^4.0.0.
[2/4] 🚚  Fetching packages...
warning [email protected]: The engine "ender" appears to be invalid.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
[1/7] ⠂ fsevents: GET https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.0.15/fse-v1.0.15-node-v51-darwi
[2/7] ⠂ gifsicle
[3/7] ⠂ jpegtran-bin
[4/7] ⠂ optipng-bin
error /Users/fdubost/Workspaces/my-project/node_modules/gifsicle: Command failed.
Exit code: 1
Command: sh
Arguments: -c node lib/install.js
Directory: /Users/fdubost/Workspaces/my-project/node_modules/gifsicle
Output:
module.js:474
    throw err;
    ^

Error: Cannot find module 'bl'
    at Function.Module._resolveFilename (module.js:472:15)
    at Function.Module._load (module.js:420:25)
    at Module.require (module.js:500:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/fdubost/Workspaces/my-project/node_modules/tar-stream/extract.js:2:10)
    at Module._compile (module.js:573:32)
    at Object.Module._extensions..js (module.js:582:10)
    at Module.load (module.js:490:32)
    at tryModuleLoad (module.js:449:12)
    at Function.Module._load (module.js:441:3)

Merci pour votre aide 😊

Cela fonctionne si j'ajoute manuellement bl à notre package.json ...

des nouvelles à ce sujet?

Pas encore, je construis un vérificateur ad-hoc commonJS qui vérifie la structure node_modules indépendamment des algorithmes de levage et de résolution de Yarn https://github.com/yarnpkg/yarn/pull/2419.
Il serait capable d'attraper tous les cas décrits dans ce bug et de nous protéger des régressions futures.

@kittens regarde ce qui se passe ici.
Le bogue n'est pas anodin, donc toute information supplémentaire est la bienvenue

Très bien, rassemblant tous les repros maintenant avec la dernière malle.
L'exemple du premier commentaire ne se reproduit plus et yarn check --verify-tree passe

Ouais, cette repro a été corrigée avec 0.18.1.

2 idées:

Y a-t-il un journal avec les résolutions en cours que je peux partager avec vous?

De plus, je peux vous donner le fichier de verrouillage qui le reproduit au travail, mais vous ne pourrez pas l'installer à cause de deps privés. Vous pourriez peut-être déranger et ignorer la récupération des paquets, et simplement jouer avec l'arbre?

@SimenB , vous avez donc un autre exemple où la résolution est cassée pour --production install?

Pour ce cas, vous pouvez essayer:

yarn install --production --verbose
yarn check --production --verify-tree

Avec la dernière branche principale.
Si vous ne souhaitez pas envoyer les journaux publiquement, envoyez-moi un message à [email protected]

Ouais, 0.18.1 était toujours cassé, je n'ai pas testé 0.19 (ou master). S'il se reproduit toujours (j'espère que non!), Je vous enverrai les journaux en privé

Fermons cette tâche car le problème du titre a été résolu.
Il y en a 2 ouverts que je n'ai pas encore revérifiés: # 2263 et # 2141, n'hésitez pas à les commenter ou à en créer un nouveau pour votre cas et à me contacter.

2all: lorsque vous dites que l'installation est incorrecte, veuillez inclure un package.json afin que d'autres puissent le reproduire.
Félicitations à @jkrems pour avoir fait un pas de plus et soumis un superbe script de repro: https://github.com/yarnpkg/yarn/issues/761#issuecomment -265823529

@bestander avez-vous également revérifié https://github.com/yarnpkg/yarn/issues/761#issuecomment -268130124?

@adamreisnz , pouvez-vous à nouveau partager le package.json s'il vous plaît?

https://github.com/yarnpkg/yarn/issues/761#issuecomment -268130124 est un problème différent.

Celui-ci échoue pour yarn install --production .

Ce problème concerne yarn install --production termine avec succès mais ne fait pas la bonne chose.

@bestander Je l'ai partagé dans le commentaire ci-dessous, https://github.com/yarnpkg/yarn/issues/761#issuecomment -268201708, bravo

Échoue toujours avec le maître (c98df16b) pour moi ...

yarn check --verify-tree lance cependant, c'est prometteur. Beaucoup d'entre eux sont cependant des développeurs.

yarn check v0.20.0-0
error "babel-preset-es2015" not installed
error "browserify-middleware" not installed
error "cheerio" not installed
error "codeceptjs" not installed
error "del-cli" not installed
error "eslint" not installed
error "eslint-config-finn" not installed
error "espower-loader" not installed
error "hashmark" not installed
error "interfake" not installed
error "nightmare" not installed
error "nightmare-upload" not installed
error "nock" not installed
error "nodemon" not installed
error "nyc" not installed
error "power-assert" not installed
error "sinon" not installed
error "supertest" not installed
error "uglifyify" not installed
error "@finn-no/express-base#nunjucks#chokidar#anymatch" not installed
error "@finn-no/express-base#unleash-client#request#json-stringify-safe" not installed
error "@finn-no/express-base#pretty-error#renderkid#css-select#domutils#dom-serializer#entities" not installed
error Found 22 errors.

L'exécution de l'application échoue en cas de manque de correspondance.

npm ls montre les autres déps manquants, ce qui est plus logique

npm ERR! extraneous: [email protected] /Users/simbekkh/repos/frontpage/node_modules/node-pre-gyp
npm ERR! missing: anymatch@^1.3.0, required by [email protected]
npm ERR! missing: entities@~1.1.1, required by [email protected]
npm ERR! missing: json-stringify-safe@~5.0.1, required by [email protected]

Et c'était l'observation / la cause du problème: https://github.com/yarnpkg/yarn/issues/761#issuecomment -268331340

Vous avez raison, cela semble être au cœur de ce problème. Il semble penser que nopt fait partie du package istanbul, au lieu de google-cloud et / ou babel-cli, et c'est peut-être pourquoi il ne l'installe pas pour les environnements de production, car istanbul n'est pas une dépendance prod.

Oh, désolé, @SimenB

yarn check --prodution --verify-tree

Je modifierai mon commentaire

Faire yarn check --verify-tree --production donne un bon résultat (cela s'accorde avec npm ls ):

yarn check v0.20.0-0
error "@finn-no/express-base#nunjucks#chokidar#anymatch" not installed
error "@finn-no/express-base#unleash-client#request#json-stringify-safe" not installed
error "@finn-no/express-base#pretty-error#renderkid#css-select#domutils#dom-serializer#entities" not installed
error Found 3 errors.

@bestander Je vous

@dashmug voulez-vous que je crée un nouveau ticket pour ce problème? C'est toujours un problème d'installation de dépendances incorrectes (bien que juste pour la production), donc je pense que c'est lié à ce ticket.

@bestander Email envoyé.
Bien que @finn-no/express-base ne soit pas disponible publiquement, les 3 autres packages de la sortie le sont, donc j'espère que vous pourrez reproduire uniquement avec des packages publics.

Dois-je ouvrir un nouveau numéro?

@adamreisnz , pourriez-vous s'il vous plaît créer un nouveau problème alors?
Je peux le reproduire mais c'est un problème différent de celui du titre

C'est lié. Probablement la même cause. Juste un symptôme différent. Je dirais que c'est une question différente, car ce n'est pas exactement la même chose que ce que dit le titre.

@SimenB , merci, je vais jeter un œil

Ok fera les gars.

@bestander Faire un paquet avec seulement ces 3 dans la sortie qui échoue le rend reproductible sur master pour moi avec juste deps publics. Ce n'est pas une reproduction minimale, mais quand même

{
  "name": "app",
  "version": "1.0.0",
  "dependencies": {
    "brakes": "^2.5.1",
    "compression": "^1.6.2",
    "envalid": "^2.4.0",
    "express": "^4.14.0",
    "object.entries": "^1.0.4",
    "prom-client": "^7.0.0",
    "response-time": "^2.3.2",
    "spaden": "^7.13.1",
    "yarn-issue-repro-package": "^1.0.0"
  },
  "devDependencies": {
    "babel-preset-es2015": "^6.18.0",
    "browserify": "^13.1.1",
    "browserify-middleware": "^7.1.0",
    "cheerio": "^0.22.0",
    "codeceptjs": "^0.4.13",
    "del-cli": "^0.2.1",
    "eslint": "^3.12.2",
    "eslint-config-finn": "^1.0.1",
    "espower-loader": "^1.0.1",
    "hashmark": "^4.1.0",
    "interfake": "^1.19.0",
    "mocha": "^3.2.0",
    "nightmare": "^2.9.0",
    "nightmare-upload": "^0.1.1",
    "nock": "^9.0.2",
    "nodemon": "^1.11.0",
    "nyc": "^10.0.0",
    "power-assert": "^1.4.1",
    "sinon": "^1.17.6",
    "supertest": "^2.0.1",
    "uglify-js": "^2.7.5",
    "uglifyify": "^3.0.4"
  }
}

package.json de yarn-issue-repro-package

{
  "name": "yarn-issue-repro-package",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "nunjucks": "^2.5.2",
    "pretty-error": "^2.0.2",
    "unleash-client": "^1.0.0-beta.7"
  }
}

Fait intéressant, cela produit 4 erreurs au lieu de 3 ...

$ yarn check v0.20.0-0                                                                                                   │├─ [email protected]
error "yarn-issue-repro-package#nunjucks#chokidar#anymatch" not installed                                              │└─ [email protected]
error "yarn-issue-repro-package#unleash-client#request#json-stringify-safe" not installed                              │✨  Done in 2.65s.
error "yarn-issue-repro-package#nunjucks#yargs#string-width#code-point-at" not installed                               │ ~/repos/yarn-issue-repro-package  vim package.json
error "yarn-issue-repro-package#pretty-error#renderkid#css-select#domutils#dom-serializer#entities" not installed      │ ~/repos/yarn-issue-repro-package  npm publish
error Found 4 errors.

Je ne suis pas sûr que ce soit le même problème ou non, mais voici la sortie (testée avec 0.19.1)

Je pense avoir trouvé la cause principale du problème d'installation.
L'échec de l'installation d'un package peut être reproduit par le package.json suivant:

{ "dependencies": {
    "bcrypt": "^1.0.1",
    "gamepad": "1.4.2"
  },
  "devDependencies": {
     "istanbul": "^1.0.0-alpha.2"
  }
}

Et puis les commandes

rm -rf node_modules yarn.lock
yarn install
rm -rf node_modules
yarn install --production
npm ls abbrev

Dans cette configuration, abbrev n'est pas installé.

abbrev est utilisé par istanbul et par nopt (comme on peut le voir à partir de yarn why abbrev ). nopt est utilisé par istanbul et node-pre-gyp (qui est utilisé par bcrypt et gamepad ).

Lors de la déduction de abbrev dans le hoister de package, le code suivant est utilisé pour déterminer la nouvelle fonction isIgnored de l'enregistrement de levage:

          // switch to non ignored if earlier deduped version was ignored
          if (existing.isIgnored() && !info.isIgnored()) {
            existing.isIgnored = info.isIgnored;
          }

abbrev est l'un des premiers enregistrements de levage à traiter. À ce moment, l'enregistrement existant est istanbul#abbrev (ignoré car istanbul est ignoré), et l'enregistrement en double est istanbul#nopt#abbrev , qui est également ignoré à l'époque pour la même raison .

Étant donné que les deux enregistrements sont ignorés à ce moment-là, la fonction ignorer n'est pas ajustée comme elle était censée le faire - car nopt ne sera pas ignoré dans une déduplication ultérieure en raison de la dépendance de node-pre-gyp . Le statut d'ignorer des deux enregistrements peut changer à tout moment, la nouvelle fonction d'ignorer devrait donc les mélanger.

Et en effet, le problème d'installation disparaît lorsque nous remplaçons ces lignes par

          // switch to non ignored if earlier deduped version was ignored
          if (existing.isIgnored()) {
            if (info.isIgnored()) {
              // both are ignored now, but any one could become non ignored later on.
              let oldIsIgnored = existing.isIgnored;
              existing.isIgnored = () => oldIsIgnored() && info.isIgnored();
            } else {
              existing.isIgnored = info.isIgnored;
            }
          }

@blexrob , bonne trouvaille!
Souhaitez-vous envoyer un PR?
Il y a un test désactivé pour "ne devrait pas perdre les dépendances lors de l'installation avec --production" dans integration.js qui devrait être corrigé maintenant

@bestander , vient de le tester, et ce correctif provoque un débordement de pile dans le test que vous avez mentionné, il ne peut donc pas être appliqué. Le cycle suivant apparaît:

d#es5-ext -> es6-symbol#es5-ext -> es6-set#es5-ext -> es6-iterator#es5-ext -> es6-map#es5-ext -> es5-ext#es6-iterator -> es6-set#es6-iterator -> es6-weak-map#es6-iterator -> event-emitter#es5-ext -> d#es5-ext

Donc, l'approche naïve des appels récursifs est sortie ...

Ouais, je crois qu'il faut un peu peaufiner mais l'idée semble correcte

J'ai un tel problème avec le module phantomjs-prebuilt (en tant que dépendance de la dépendance) avec le fil 0.27.5-1.
Alors maintenant, je fais dummy yarn add phantomjs-prebuilt , avant yarn install --production .

J'ai le regret de dire que cela semble toujours être un problème dans Yarn 1.3.2.
Mes builds sur Netlify échouent lorsque j'utilise Yarn 1.3.2 mais que je réussis avec Yarn 0.18.2.
Les erreurs de construction avec un cannot find module 'are-we-there-yet' et uniquement avec un indicateur de production.

@adamreisnz , ce fil est trop gros pour suivre tous les problèmes.
Pourriez-vous en créer un nouveau avec un script de repro?

@bestander fait, merci.

Pour quelqu'un qui ne peut toujours pas le faire fonctionner et ne veut pas installer jq peut utiliser

$ python -c "import json; p = json.loads(open('package.json').read()); del p['devDependencies']; open('package.json', 'w').write(json.dumps(p, indent=2));"

je suis sur le fil 1.17.3 et le nœud v10.16.2 en lerna monorepo. toujours confronté au même problème.

Je peux le confirmer aussi.
J'ai beaucoup de dépendances, mais lorsque j'utilise yarn install --production , seuls deux modules sont installés.
Remarquable cependant, je suis sur un Lerna monorepo similaire à @hannadrehman avec des espaces de travail Yarn , ce qui peut expliquer le comportement extrême.

Version du fil: 1.22.0
Nœud: v12.16.1

npm install --production fonctionne parfaitement cependant.

@hannadrehman est-ce que le projet en question est un package de votre monorepo?

Même problème que @ TAnas0

Cette page vous a été utile?
0 / 5 - 0 notes