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
@ 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é:
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?
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?
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.
@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
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
Celui-ci ne se reproduit pas trop https://github.com/yarnpkg/yarn/issues/761#issuecomment -260975012 et https://github.com/yarnpkg/yarn/issues/761#issuecomment -265823529
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
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.