Yarn: `yarn install --production` não instala dependências corretas

Criado em 12 out. 2016  ·  115Comentários  ·  Fonte: yarnpkg/yarn

Ao executar yarn install --production ele não instala as dependências necessárias de forever . Isso parece estar relacionado a ter nodemon em devDependencies .

Resposta de erro:

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

Criei um aplicativo de teste aqui:
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

Comentários muito úteis

Olá a todos, desculpem por vocês estarem tendo esse problema há um bom tempo.
Vou atribuir esse problema a mim mesmo e agora é uma prioridade alta, vou tentar corrigi-lo durante as férias.
Ajuda e PRs com testes de interrupção isolados ou uma correção (idealmente) são muito bem-vindos.

Todos 115 comentários

@ Daniel15 Acho que isso se deve ao fato de que o nodemon está tendo a versão mais recente do minimatch.

A função de vinculador atualmente leva em ambas as dependências e dev dep. Para a produção de argumentos, isso deve ser evitado.

Mesmo em fios normais, instale sem argumentos de produção. Apenas a versão mais recente é instalada no caminho real. Isso também tem que ser verificado.

Estou tendo um problema semelhante ao executar yarn install --production e, em seguida, tentar executar minha compilação usando webpack (executar yarn install funciona bem).

> 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)

e se bem me lembro, as tentativas anteriores mostraram erros semelhantes com outro pacote (não apenas graceful-fs )

Estou ficando muito parecido também ... yarn install funciona muito bem. mas com a sinalização --production eu obtenho isto:

> 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)

Pode reproduzir um problema semelhante com:

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

Isso instalará is-glob mas não sua dependência 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.

Parece "esquecer" o caminho de dependência gulp#liftoff enquanto atravessa ..?

EDIT: Exemplo menor:

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

Também confirmou que remover devDependencies antes de executar yarn --prod instala a árvore de dependências correta.

Minha equipe de software encontrou esse problema, especificamente com o pacote prr que é uma dependência de less e pouchdb . Muitos outros pacotes também estavam faltando na construção de --production mas prr foi o primeiro a causar uma falha em nosso produto. Este problema tem sido um obstáculo para nós, pois o tamanho do nosso instalador aumentaria significativamente se incluíssemos os pacotes dev, portanto, voltamos a usar o npm.

FWIW: Posso contornar o problema excluindo a seção devDependencies do package.json antes de executar yarn na produção.

como @gihrig disse, executar npm prune --production pode remover as devDependencies, o que ajuda a contornar esse problema.

como @gihrig disse, executar o npm prune --production pode remover as devDependencies, o que ajuda a contornar esse problema.

A principal vantagem do Yarn sobre o npm é um node_modules dir determinístico, ou seja, o mesmo em desenvolvimento, CI e produção fora da caixa. Executar npm prune --production produz o mesmo comportamento?

Minha solução atual é apenas instalar devDependencies na produção também. O disco é barato (especialmente na AWS) e uma instalação determinística é muito mais importante para mim do que o espaço em disco. Portanto, minha "solução alternativa" é apenas agir como se yarn --production não existisse no momento.

@tanx npm prune --production apenas remova as devDependencies. E em meus testes sempre os mesmos módulos foram removidos. Por outro lado, sim, o espaço em disco é barato, então talvez agir como se yarn --production não existisse seja uma solução melhor :)

@tanx npm prune --production apenas remove as devDependencies. E em meus testes sempre os mesmos módulos foram removidos.

Esta é precisamente a mentalidade "funciona na minha máquina" descrita na postagem do blog Yarn . O problema é que você está permitindo que o npm mude o estado de node_modules sem a verificação de integridade do fio por meio do arquivo yarn.lock .

Esperançosamente, as soluções alternativas discutidas serão discutidas em breve por uma atualização do yarn para respeitar os departamentos de desenvolvimento e produção. Nesse ínterim, realmente há muito o que reclamar com o hack de pós-processamento "npm prune".

A coisa yarn why descrita acima não está relacionada. Parece ser apenas um efeito colateral de como o código why está procurando os pacotes.

Tentei encontrar uma boa maneira de fazer isso sem adicionar uma passagem adicional para propagar a visibilidade depois que o gráfico foi percorrido uma vez. Não tenho certeza se seria aceitável apenas dividir a visibilidade em uma etapa separada ..?

Existem alguns casos interessantes também, não se trata apenas de resolver adequadamente a visibilidade:

  • A é uma dependência opcional de uma dependência de produção
  • B é uma dependência não opcional de uma dependência dev
  • C é uma dependência não opcional de ambos

Nesse caso, o sinalizador opcional de C depende de dev vs. prod. Em dev, seria não opcional, em prod, seria opcional. Apenas herdar a sinalização opcional de um dos pais (ou sempre herdá-la do pai prod) pode causar estranheza.

Isso ainda não foi corrigido em 0.17.2 😢

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

yarn

node index.js # works

yarn --prod

node index.js # explodes

/ cc @jkrems

Também não parece fixo para mim na versão 0.17.2 (HearthSim / Joust # 169).

Vou reabri-lo, pois ele pode ser facilmente reproduzido com as instruções de @SimenB .

@wyze O problema pode ser a própria instalação, e não a remoção?

rm -rf node_modules/ && yarn && npm prune --production && node index.js falha com o mesmo erro.

rm -rf node_modules/ && npm i && npm prune --production && node index.js funciona embora.

Eu acho que fio e npm não devem ser usados ​​ao mesmo tempo, então pode ser uma coincidência que ele produza o mesmo erro.

Diferenciar node_modules depois de npm i e yarn mostra que o fio não produz "_requiredBy" , provavelmente porque npm prune bagunça depois de yarn install . Essa informação está disponível no arquivo de bloqueio, então não deve ser um problema, deve?

Mesmo problema aqui, estávamos testando a construção de produção no docker e descobrimos que com yarn --production o pacote mime estava faltando, mesmo se o módulo pai send (usado por express) estivesse instalado .

Acho que esse problema deve ser tratado com prioridade máxima, pois causa compilações imprevisíveis.

Como solução alternativa, estou simplesmente removendo a seção devDependencies de package.json em meu script de construção.

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

Seguindo o conselho de @ dy-dx, escrevi um ponto de entrada personalizado para o Docker para corrigir esse problema durante o desenvolvimento:

Em primeiro lugar, você deve instalar o jq em seu Dockerfile adicionando esta linha em algum lugar:

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

Em seguida, adicione este script em algum lugar e use-o como Dockerfile [ENTRYPOINT] ou docker-compose entrypoint entrypoint.sh

Use seu comando preferido para Dockerfile [CMD] ou docker-compose command Eg npm start

O mesmo script pode ser usado em CI com alguma edição para construir a imagem

@SimenB Você pode remover node_modules de seu pacote entries-test e tentar?

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

Extraia o tarball v1.0.1, há uma pasta node_modules com define-properties e outros módulos. E nenhum deles tem qualquer arquivo *.js .

@torifat Huh, como isso apareceu? Não deveria ser possível incluir node_modules sem usar bundledDependencies ...
Vou tentar empurrar um limpo (excluí os projetos, terei que recriar).

@torifat Parece que é culpa do fio.

$ 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

Usar npm pack funciona conforme o esperado (no mesmo diretório).

$ 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

Parece que o Yarn está tão empenhado em incluir changelog , readme e package.json que até inclui node_modules ...

Usando [email protected]

@torifat publicado 1.0.2 agora (usando npm para evitar o bug que acabamos de mencionar), ainda o mesmo problema

Abri o # 2047 para o bug relacionado ao node_modules, mas é uma pista falsa neste problema, já que minha reprodução ainda é válida com um tarball apropriado publicado.

(desculpe pelo spam para as pessoas inscritas, vou parar agora)

@SimenB Obrigado pelo seu tempo. Eu descobri o bug.

Isso parece estar relacionado ao # 2104, que acabei de abrir. O node_modules/.bin após a instalação do 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

Corrigido via # 2116.

O # 2116 já foi incorporado? Não consigo ver no histórico de commits. Parece prematuro fechar um monte de problemas antes que uma correção esteja disponível, pelo menos no master, se não em uma versão marcada. Além disso, parece que o # 2116 está falhando nas três verificações. Estou esquecendo de algo?

Este ainda é um problema na v0.18.0, que inclui (# 2116).

sim, posso confirmar que este problema ainda está presente em 0.18.0

Pelo que vejo, o # 2116 deveria ter introduzido o teste para esse problema ( test.concurrent ('- o sinalizador de produção ignora as dependências de desenvolvimento' ... ou estou errado?

O teste não verifica o comportamento correto para dependências transitivas:
No meu caso, o problema é uma dependência compartilhada (lru-cache) entre uma dependência prod (minimatch v2.0.0) e uma dev (useragent v2.1.9). Esse dependente compartilhado não está instalado em --production , embora a dependência do produto exija isso.

@beheh Não vejo se minimatch usa lru-cache , talvez seja por isso que não está instalado em produção?

Estou fazendo alguns testes com 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.

este é o caso ilustrado por @SimenB

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

@SharpEdgeMarshall Obrigado pelo teste. Vou adicioná-lo como um caso de teste.

@torifat pode considerar reabri-lo também

@SharpEdgeMarshall Tentei o seguinte e está funcionando. Precisa descobrir o problema real.

screenshot 2016-12-06 21 18 44

@SimenB precisa verificar antes de reabrir. Isso pode acontecer devido a optionalDependencies também. Que tem outro problema em aberto.

@torifat minha reprodução ainda acontece: https://github.com/yarnpkg/yarn/issues/761#issuecomment -260975012

EDIT: Que não tem dependências opcionais, grep optional yarn.lock sai com 1

Agora falha em Error: Cannot find module 'object-keys' vez de perder 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.

Parece que agora lida com um nível mais profundo, mas depois falha

@SimenB Acabei de tentar com o seu:

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

E está funcionando bem para mim. Você pode fazer um yarn cache clean e tentar novamente?

Não, falha

@SimenB Você pode compartilhar seu arquivo 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)

Para mim, o exemplo de SimenB não funciona com 0.18.0 mesmo depois de 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 Obrigado. Parece que meu cache teve problemas. Depois de limpar meu cache, ele está falhando. Mas, com um erro diferente. Dê-me algum tempo para investigar.

A propósito, eu recomendo usar https://github.com/Mottie/Octopatcher neste tópico

Muito prático com muitas linhas de saída

image

Vou parar de enviar spam agora

@SimenB Falha em v0.18.0 mas não consegue reproduzir no último master .

ATUALIZAÇÃO: Estranho! Está falhando de novo 😕

@torifat , posso confirmar que não funciona com o mestre (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)

Eu tenho os mesmos problemas (alguns pacotes não são instalados com a bandeira --production ) com 0.17.10 estável atual:

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

Mas quando tento a compilação noturna atual Yarn 0.19.0-20161207.1241 todos os pacotes necessários foram instalados corretamente para meu aplicativo:

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 pode tentar a última compilação noturna e confirmar que o problema persiste.

Usado em meus contêineres docker: https://gist.github.com/nodkz/b843d65a3430a4f510e5f5eb0cc759d2

@nodkz 18 está lançado e estável (eu acho?), mas como pode ser visto no post diretamente acima do seu, mestre (a partir de 2 dias atrás pelo menos) ainda tem o bug

Acho que ainda requer install yarn@rc :

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

Isso é novo, eu tenho 0,18 alguns dias atrás apenas instalando. De qualquer forma, o bug ainda é reproduzível em 0,18.

@nodkz Repro é:

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

Sim, enfrentando problemas semelhantes com nossos projetos também:

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')"

Falha com 0,18 e o branch master mais recente.

Acordado. Ainda é capaz de reproduzir com o mais recente.

Acho que meu problema é semelhante ou igual a este. O build está falhando no Heroku, mas apenas para o ambiente de produção. O cache está desativado.

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

Eu também tenho esse problema também. Ainda estou usando yarn install para produção no momento, já que yarn install --production não instala corretamente as dependências certas.

Infelizmente, não posso fazer isso, pois está codificado para yarn install --production no buildpack do Heroku, eu acho (ref https://github.com/heroku/heroku-buildpack-nodejs/issues/337)

@adamreisnz Desculpe, eu estava me referindo ao problema original, não seu.

Para contornar o seu problema, sugiro que você coloque todos os devDependencies em dependencies por enquanto, até que o problema seja corrigido.

@dashmug Ah ok, sem problemas.

De qualquer forma, prefiro usar npm no Heroku por enquanto, até que o Yarn esteja mais estável, em vez de mexer em soluções hacky. Coloquei yarn.lock no meu .gitignore para que não seja carregado no repo / heroku. Dessa forma, ainda posso usar o Yarn localmente, mas isso não afetará as compilações no Heroku.

@adamreisnz Isso vai contra o seu propósito de usar yarn , você não acha?

@dashmug Na verdade não, pelo menos não para nós. Não o estou usando para bloquear versões de pacote no lugar. Temos dependências muito atualizadas e nenhum problema de "funciona na minha máquina". Meu principal motivo para mudar para o yarn em vez do npm foi a velocidade, que para aplicativos complexos com muitas dependências eu vi ir de 5 minutos para npm install a 22 segundos com yarn.

Contanto que o fio seja instável, posso viver com um processo de construção um pouco mais lento no Heroku, contanto que eu possa usar o fio localmente para desenvolvimento e ter instalações rápidas :)

Yarn é anunciado como sendo praticamente um substituto imediato para o npm. No entanto, alguns dos problemas que encontramos e que ainda não foram resolvidos, como este, nos impedem de usá-lo como tal. Portanto, eu o vejo como uma ferramenta extra no momento, que é útil para uma coisa, mas ainda não existe para outra. Não tenho dúvidas de que com o tempo vai funcionar muito bem :)

Isso parece ter sido corrigido para mim na versão 0.18.1.

O Heroku estava usando 0.18.1 no momento em que falhou, então ainda não corrigido.

Este problema foi corrigido para mim na versão 0.18.1.

Minha reprodução anterior foi corrigida em 0,18.1 🎉

Vou tentar amanhã com um aplicativo real

0.18.1 corrige meus problemas. Eu sou um campista feliz 🎉

Tentei 0.18.1 com um aplicativo não trivial que estava falhando e parece funcionar agora! 🎉

Acho que vou tentar novamente em breve :)

Desculpe, ainda não estou funcionando com 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

Definir NODE_MODULES_CACHE=false também não ajudou.

Aqui está a árvore de dependência:

├─┬ [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] 

Acho que o problema é a dependência profunda via google-cloud . Este é um módulo de produção, e bable-cli e instanbul são apenas para desenvolvimento.

Além disso, quando eu uso yarn why abbrev , ele não consegue pegar os google-cloud e babel-cli dependentes dos pais:

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 Devo levantar uma nova questão para isso ou não?

istanbul#nopt também parece errado, na saída de why .
Estou no meu jeito de trabalhar agora, testarei em um aplicativo real então

@SimenB obrigado, deixe-me saber se você precisar de mais informações, por exemplo, toda a minha lista de módulos package.json.

Edit: na verdade aqui é só para garantir, já que vou dormir agora;

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

Isso ainda falha para o aplicativo no trabalho. Parece que Yarn é incapaz de seguir caminhos profundos. Aqui está npm ls entities depois de 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]

Da mesma forma que @adamreisnz , yarn why não pega a árvore correta.

$ 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 também parece errado na saída de why.

Você está certo, esse parece ser o cerne do problema. Parece pensar que nopt faz parte do pacote istanbul , em vez de google-cloud e / ou babel-cli , e talvez seja por isso que não está instalando para produção ambientes, porque istanbul não é uma dependência prod.

Olá a todos, desculpem por vocês estarem tendo esse problema há um bom tempo.
Vou atribuir esse problema a mim mesmo e agora é uma prioridade alta, vou tentar corrigi-lo durante as férias.
Ajuda e PRs com testes de interrupção isolados ou uma correção (idealmente) são muito bem-vindos.

Temos o mesmo problema no env do produto com a lib bl que é uma dependência das dependências opcionais 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)

Obrigado pela ajuda 😊

Funciona se eu adicionar manualmente bl ao nosso package.json ...

Alguma novidade sobre isso?

Ainda não, estou construindo um verificador commonJS ad-hoc que verifica a estrutura node_modules independente dos algoritmos de içamento e resolução do Yarn https://github.com/yarnpkg/yarn/pull/2419.
Ele seria capaz de capturar todos os casos descritos neste bug e nos proteger de futuras regressões.

@kittens está
O bug não é trivial, então qualquer informação adicional é bem-vinda

Certo, coletando todas as repros agora com o baú mais recente.
O exemplo no primeiro comentário não se reproduz mais e yarn check --verify-tree passa

Sim, essa reprodução foi corrigida com 0.18.1.

2 ideias:

Existe algum registro com as resoluções acontecendo que eu possa compartilhar com você?

Além disso, posso fornecer o arquivo de bloqueio que o reproduz no trabalho, mas você não poderá instalá-lo por causa de dependências privadas. Você pode ser capaz de bagunçar e pular a busca de pacotes e apenas bagunçar a árvore?

@SimenB , então você tem outro exemplo em que a resolução foi quebrada para - instalação de produção?

Nesse caso, você pode tentar:

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

Com o mais recente ramo mestre.
Se você não quiser enviar logs publicamente, envie uma mensagem para [email protected]

Sim, 0.18.1 ainda estava quebrado, não testei 0.19 (ou mestre). Se ainda reproduzir (espero que não!), Enviarei os registros em particular

Vamos encerrar esta tarefa porque o problema do título foi resolvido.
Há 2 abertos que ainda não verifiquei: # 2263 e # 2141, sinta-se à vontade para comentar aí ou crie um novo para o seu caso e me envie uma cópia.

2todos: quando você comentar que a instalação está incorreta, inclua um package.json para que outros possam reproduzi-lo.
Parabéns a @jkrems por dar um passo adiante e enviar um script de reprodução incrível: https://github.com/yarnpkg/yarn/issues/761#issuecomment -265823529

@bestander , você também verificou novamente https://github.com/yarnpkg/yarn/issues/761#issuecomment -268130124?

@adamreisnz , você pode compartilhar o package.json novamente, por favor?

https://github.com/yarnpkg/yarn/issues/761#issuecomment -268130124 é um problema diferente.

Esse falha para yarn install --production .

Este problema é sobre yarn install --production terminar com sucesso, mas não está fazendo a coisa certa.

@bestander Eu compartilhei no comentário abaixo disso, https://github.com/yarnpkg/yarn/issues/761#issuecomment -268201708, cheers

Ainda falha com o mestre (c98df16b) para mim ...

yarn check --verify-tree lançamentos, porém, isso é promissor. Muitos deles são deps dev.

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.

Executando o aplicativo, ele falha ao perder anymatch.

npm ls mostra outras dependências ausentes, o que faz mais sentido

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]

E esta foi a observação / causa do problema: https://github.com/yarnpkg/yarn/issues/761#issuecomment -268331340

Você está certo, esse parece ser o cerne do problema. Parece pensar que nopt faz parte do pacote istanbul, ao invés de google-cloud e / ou babel-cli, e talvez seja por isso que não está instalando para ambientes de produção, porque istanbul não é uma dependência de prod.

Oh, desculpe, @SimenB

yarn check --prodution --verify-tree

Vou editar meu comentário

Fazer yarn check --verify-tree --production dá uma boa saída (concorda com 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 Enviarei um e-mail para você package.json, yarn.lock e o registro de instalação detalhado 😄

@dashmug , você quer que eu crie um novo tíquete para esse problema? Ainda é um problema de dependências incorretas sendo instaladas (embora apenas para produção), então acho que está relacionado a este ticket.

@bestander Email enviado.
Enquanto @finn-no/express-base não está disponível publicamente, os outros 3 pacotes na saída estão, então esperançosamente você pode reproduzir somente com pacotes públicos.

Devo abrir um novo problema?

@adamreisnz , você poderia criar um novo problema então?
Posso reproduzi-lo, mas é um problema diferente do título

Tem a ver. Provavelmente a mesma causa. Apenas um sintoma diferente. Eu colocaria isso como um problema diferente, pois não é exatamente o mesmo que o título diz.

@SimenB , obrigado, vou dar uma olhada

Ok vai fazer caras.

@bestander Fazer um pacote com apenas aqueles 3 na saída que falha torna-o reproduzível no master para mim apenas com recursos públicos. Não é uma reprodução mínima, mas ainda assim

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

Curiosamente, ele produz 4 erros em vez 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.

Não tenho certeza se é o mesmo problema ou não, mas aqui está o resultado (testado com 0.19.1)

Acho que encontrei a causa raiz do problema de instalação.
A falha ao instalar um pacote pode ser reproduzida pelo seguinte package.json:

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

E então os comandos

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

Nesta configuração, abbrev não está instalado.

abbrev é usado por istanbul e por nopt (como pode ser visto em yarn why abbrev ). nopt é usado por istanbul e node-pre-gyp (que é usado por bcrypt e gamepad ).

Ao desduplicar abbrev no elevador de pacote, o seguinte código é usado para determinar a nova função isIgnored do registro de içamento:

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

abbrev é um dos primeiros registros de içamento a serem processados. Nesse momento, o registro existente é istanbul#abbrev (ignorado porque istanbul é ignorado), e o registro duplicado é istanbul#nopt#abbrev , que também é ignorado no momento pelo mesmo motivo .

Como ambos os registros são ignorados no momento, a função de ignorar não é ajustada como deveria - porque nopt não será ignorado em uma desduplicação posterior por causa da dependência de node-pre-gyp . O status de ignorar de ambos os registros pode mudar a qualquer momento, portanto, a nova função de ignorar deve misturá-los.

E, de fato, o problema de instalação desaparece quando substituímos essas linhas por

          // 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 , ótimo achado!
Você enviaria um PR?
Há um teste desabilitado para "não deve perder dependências ao instalar com --production" em integration.js que deve ser corrigido agora

@bestander , acabou de testá-lo e essa correção causa um estouro de pilha no teste que você mencionou, portanto, não pode ser aplicado. O seguinte ciclo aparece:

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

Então, a abordagem de chamada recursiva ingênua está fora ...

Sim, acredito que precisa de um pequeno ajuste, mas a ideia parece correta

Eu tenho um problema com o módulo phantomjs-prebuilt (como dependência de dependência) com yarn 0.27.5-1.
Então agora eu faço o dummy yarn add phantomjs-prebuilt , antes de yarn install --production .

Lamento dizer que isso ainda parece ser um problema no Yarn 1.3.2.
Minhas compilações no Netlify estão falhando quando uso o Yarn 1.3.2, mas com êxito com o Yarn 0.18.2.
Os erros de compilação com cannot find module 'are-we-there-yet' e apenas com sinalizador de produção.

@adamreisnz , este tópico é muito grande para rastrear todos os problemas.
Você poderia criar um novo com script repro?

@bestander pronto, obrigado.

Para quem ainda não conseguiu fazer funcionar e não quer instalar o jq pode usar

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

estou no fio 1.17.3 e no nó v10.16.2 em lerna monorepo. ainda enfrentando o mesmo problema.

Eu também posso confirmar.
Eu tenho muitas dependências, mas quando uso yarn install --production , apenas dois módulos são instalados.
Notável, porém, estou em um monorepo Lerna semelhante a @hannadrehman com espaços de trabalho Yarn , o que pode explicar o comportamento extremo.

Versão do fio: 1.22.0
Nó: v12.16.1

npm install --production funciona perfeitamente embora.

@hannadrehman o projeto em questão é um pacote do seu monorepo?

Mesmo problema que @ TAnas0

Esta página foi útil?
0 / 5 - 0 avaliações