Yarn: Substitua o uso de novo construtor de Buffer obsoleto / inseguro

Criado em 7 mar. 2018  ·  84Comentários  ·  Fonte: yarnpkg/yarn

Qual é o comportamento atual?

yarn usa o construtor new Buffer() obsoleto e causa avisos de depreciação quando executado com NODE_PENDING_DEPRECATION=1 .

$ ag '\bBuffer\('
src/registries/npm-registry.js
340:        const pw = new Buffer(String(password), 'base64').toString();
341:        return 'Basic ' + new Buffer(String(username) + ':' + pw).toString('base64');

src/util/fs.js
835:const cr = new Buffer('\r', 'utf8')[0];
836:const lf = new Buffer('\n', 'utf8')[0];

Qual é o comportamento esperado?

yarn não deve usar o construtor Buffer obsoleto / inseguro. De acordo com o aviso de descontinuação, new Buffer() deve ser substituído por Buffer.alloc() , Buffer.allocUnsafe() ou Buffer.from() ; o pacote safe-buffer é outra opção.

Mencione seu node.js, yarn e versão do sistema operacional.

$ node -v
v8.9.4

$ yarn -v
1.5.1

$ uname -a
Linux 4.15.6-300.fc27.x86_64 #1 SMP Mon Feb 26 18:43:03 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
cat-bug cat-compatibility high-priority triaged

Comentários muito úteis

Para sua informação: Acabei de passar pelas dependências do yarn e há dois que ainda chamam new Buffer() :

  • tar-stream (corrigido, mas ainda dependemos de uma versão mais antiga)
  • v8-compile-cache (não corrigido)

Provavelmente precisaremos atualizá-los.

Todos 84 comentários

Recebendo este mesmo aviso no macOS. Eu acredito que # 5704 é uma duplicata disso.

Como uma solução alternativa por enquanto, criei um script ~/bin/node que vem antes de (Homebrew instalado) /usr/local/bin/node em meu $PATH :

#!/bin/bash

/usr/local/bin/node --no-deprecation "$@"

Para sua informação: Acabei de passar pelas dependências do yarn e há dois que ainda chamam new Buffer() :

  • tar-stream (corrigido, mas ainda dependemos de uma versão mais antiga)
  • v8-compile-cache (não corrigido)

Provavelmente precisaremos atualizá-los.

@martinstuecklschwaiger quando a correção é feita ??

@marvinhagemeister v8-compile-cache acaba de lançar a versão 2.0.0, que corrigiu o bug. Espero que possamos atualizar em breve para uma nova versão.

@fengerzh @imsnif já comprometeu a nova versão para master https://github.com/yarnpkg/yarn/commit/546a1576edbf701021ce65e3dd8daff267083f52 🎉

Quando você planeja lançar uma nova versão com essa correção? Não consegui encontrar nenhuma informação sobre como você lida com lançamentos.

Vejo que o rótulo high-priority foi usado neste problema. Isso também não significa que você deseja enviar a correção o mais rápido possível? Não apenas consertando o mais rápido possível.

EDIT: Não queria soar agressivo ou exigente de forma alguma, estou apenas curioso para saber como você aborda esses high-priority questões. A razão pela qual perguntei foi porque é irritante receber um aviso sobre isso para cada nova instância de shell que eu inicio.

Este aviso começou a aparecer depois que eu atualizei do nó v0.9.x para v0.10.1

@ piotr-cz, você quer dizer que v10.1, 0.10 é bem antigo.

Obrigado, eu quis dizer que o aviso começou a aparecer após a atualização de v9.x para v10.1.0

Ainda estou recebendo este aviso com yarn 1.6.0

yarn install v1.6.0
(node:22339) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security 
and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or 
Buffer.from() methods instead.

Minha versão node.js, yarn e sistema operacional

node -v
v10.1.0

yarn -v
1.6.0

uname -a
Darwin *****.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; 
root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64

Algum progresso aqui? Gostaríamos muito de usar o nó 10 em nosso projeto sem nenhuma solução alternativa 🔥

É apenas um aviso. Por que isso o impediria de usá-lo?

O mesmo problema aqui e faz com que meu tema do Roots Sage não compile caso ele não seja implantado. Veja também https://discourse.roots.io/t/buffer-deprecated-yarn-warning/12525

@teohhanhui Avisos de longa duração são problemáticos porque obscurecem outros avisos mais úteis: Não seria razoável esperar que os desenvolvedores examinassem todos os avisos em cada construção e desconsiderassem mentalmente apenas os "aceitáveis". Portanto, é comum (e totalmente razoável) tratar todos os avisos como erros. Esta não é uma reclamação sobre fios, o que é ótimo; mas a frase "É apenas um aviso" levanta altos alarmes mentais.

Existem empresas de software / etc grandes e extremamente prósperas, nomes de marca que todos conhecemos, que têm regras para toda a empresa, como: tratar avisos como erros ou excluí-los, mas nunca gaste mão de obra humana examinando listas de avisos rotineiramente. Pelo motivo mencionado acima.

Isso não quer dizer que este é um conselho perfeito em qualquer lugar, mas não é incomum e muito bem demonstrado como viável e valioso.

Se você for tratar todos os avisos como erros, não teria uma maneira de ignorar / colocar os avisos na lista de permissões? Mas, de qualquer forma, não vejo como é a culpa de yarn que você escolheu fazer isso. yarn não está quebrado neste caso.

Desculpe fazer isso, mas tenho que bloquear este problema, pois as pessoas não parecem estar lendo os comentários anteriores. Aqui está o resumo:

  • Este problema ainda não foi resolvido (a partir do Yarn 1.6.0)
  • Sim, nós, como equipe do yarn, estamos cientes e trabalhando muito para consertar isso e lançar uma nova versão. Você pode seguir # 5769 para ver o progresso (por favor, não use esse PR como outro fórum de discussão para isso)
  • Nós descobrimos um problema com relação aos links simbólicos no Windows ao usar o Yarn no Nó 10, que pode fazer com que as instalações parem com uma recursão infinita. Este problema também está sendo abordado em # 5769

Peço desculpas em nome de toda a equipe Yarn pelo problema e pelo atraso.

Atualização: o PR mencionado acima está agora mesclado. Vamos lançar uma nova versão o mais rápido possível.

A versão 1.7.0 com a correção acaba de entrar no ar. Obrigado pela sua paciência!

@teohhanhui estava usando em um único repositório dentro de uma pilha lerna, então yarn warning kill do processo lerna (sim, pode ser mais uma configuração de lerna aqui, mas os avisos de limpeza também corrigem o problema para nós)
@BYK obrigado byk pelo seu esforço

@BYK Ainda estou vendo avisos de buffer com 1.7.0 do Homebrew:

$ NODE_OPTIONS=--trace-warnings yarn outdated
yarn outdated v1.7.0
(node:44538) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
    at showFlaggedDeprecation (buffer.js:159:11)
    at new Buffer (buffer.js:174:3)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:4105:6)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:4228:12)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:56449:11)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.<anonymous> (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:43234:13)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)

@ezzatron O mesmo aqui.

@ezzatron @AlexanderOMara
Acho que o aviso só aparece depois de executar o fio pela primeira vez após a atualização da mistura. Ao executar o fio pela segunda vez, o aviso se foi para mim.

Este é o estado atual da minha máquina:

yarn -v
1.7.0

node -v
v10.1.0

uname -a
Darwin *****.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64

Aqui está meu log de terminal

$ yarn
yarn install v1.7.0
(node:73733) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[1/4] 🔍  Resolving packages...
success Already up-to-date.
✨  Done in 0.47s.

$ yarn
yarn install v1.7.0
[1/4] 🔍  Resolving packages...
success Already up-to-date.
✨  Done in 0.40s.

Olá, ainda estou tendo DeprecationWarning ao fazer yarn check

$ yarn check
yarn check v1.7.0
[---------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 0/1697(node:84081) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methodsinstead.

Execute yarn upgrade , é provável que você dependa de upath devido a algum pacote e ainda tenha uma versão instalada.

@rpellerin Obrigado, mas upath já está atualizado
Mesmo depois de yarn upgrade , ainda recebo o mesmo aviso, mas não no mesmo momento que a versão 1.6
Além disso, após alguns testes, não está limitado a yarn check

$ yarn
yarn install v1.7.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[-----------------------------------------------------------------------------------------------------------------------------------------------------------------------] 0/943(node:7042) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 24.87s.

Testado com o node v10.1.0 e v10.2.0, estou no OSX e uso brew para instalar o yarn (usando --without-node param)

@Justkant você pode executar NODE_OPTIONS=--trace-warnings yarn ? Isso dirá qual pacote dispara o aviso.
Então você pode executar yarn why <package> . Vou responder de acordo.

Sim, foi resolvido após a atualização para 1.7.0
Obrigado @BYK

@rpellerin

yarn install v1.7.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[----------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 0/943(node:8741) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
    at showFlaggedDeprecation (buffer.js:159:11)
    at new Buffer (buffer.js:174:3)
    at Object.<anonymous> (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:68767:20)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:129185:17)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports.id (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:107036:12)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.Object.defineProperty.value (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:62287:14)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
✨  Done in 30.10s.

Mas por que eu faria um yarn why <package> ? O aviso não está ligado às minhas embalagens locais, mas apenas ao fio em si, não?

Achei que fosse por causa de um pacote. Tentar usar fio do npm?
npm i -g yarn

Usar o fio do npm parece funcionar corretamente

yarn não mostra nenhum aviso para mim, mas yarn outdated sim.

$ NODE_OPTIONS=--trace-warnings yarn outdated
yarn outdated v1.7.0
(node:28493) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
    at showFlaggedDeprecation (buffer.js:159:11)
    at new Buffer (buffer.js:174:3)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:4105:6)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:4228:12)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:56449:11)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
    at Object.<anonymous> (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:43234:13)
    at __webpack_require__ (/usr/local/Cellar/yarn/1.7.0/libexec/lib/cli.js:22:30)
✨  Done in 1.10s.

Atenção: parece que o antigo construtor de buffer ainda é usado para a CLI global. Ainda recebo a mensagem de erro ao lidar com comandos yarn global . @BYK

Ack! Obrigado pelos relatórios detalhados. Vou examinar isso hoje.

Ok, o pacote ofensivo é sshpk, que é exigido por http-signature que é exigido por request . Há um PR para consertar, mas não parece estar recebendo amor. Alguém conhece alguém da Joyent para nos ajudar?

Ainda problema a partir do yarn 1.7.0 com nó> 10.0.0

Corrigido o problema desinstalando o nó que acompanha o yarn e instalando o 8.11.2 estável em https://nodejs.org/en/

Corrigido o problema ao desinstalar o nó que veio com o yarn e instalou [versão antiga] ...

Não é realmente "consertar" se você simplesmente voltar para uma versão anterior ao seu uso obsoleto por ser insegura.

O problema do link @mikestepanov parece ter sido resolvido. O arquivo ofensivo agora usa Buffer.from :

https://github.com/joyent/node-sshpk/blob/175758a9473523409339e6c519c470c808ca03de/lib/algs.js

Parece ter sido lançado como 1.14.2, que corresponde ao intervalo de versão necessária de http-signature .

IOW, parece que simplesmente atualizar o arquivo de bloqueio do yarn e cortar uma nova versão deve corrigir isso.

A única coisa que ajudou foi deletar o arquivo yarn.lock, como disse @pluma

FWIW, esse bug quebrou getstorybook para mim porque ele tentou analisar stderr, no qual os avisos são impressos. Não tenho certeza se storybook-cli foi atualizado para contornar isso, mas vale a pena mencionar que isso é mais do que um problema cosmético.

@BYK A situação com este bug é muito triste para desenvolvedores de todo o mundo, você pode publicar uma versão corrigida do yarn (1.7.1 ou smth) com a versão aprimorada do pacote dentro, conforme proposto em https://github.com/ yarnpkg / yarn / issues / 5477 # issuecomment -396903361, por favor? 🙏

Este commit (do mês passado) parece que deveria encerrar este problema, mas ainda estou vendo isso com o nó 10.5.0 & yarn 1.9.0-20180621.1511 (noturno). Como a situação de @Gurenax , o aviso só aparece durante a execução inicial para mim (exclua node_modules e execute yarn ). Caso seja útil para outros, incluí algumas notas relacionadas ao que descobri / fiz abaixo. Parece que as dependências de yarn estão desatualizadas, já que pode-se ver new Buffer chamadas nas atuais compilações de JS autônomo noturnas.

  1. Verifique com um projeto vazio / mínimo para ver se o aviso persiste. (por exemplo, mkdir empty-project; cd empty-project; npm init empty-project; yarn ).
  2. Se o aviso aparecer lá, então você pode precisar atualizar o yarn (tente o rc mais recente: v1.8 embora v1.7.0 devesse consertá-lo). No meu caso, isso não aconteceu no mínimo, então tive que cavar mais fundo. Primeiro, executei yarn upgrade mas isso não pareceu resolver o problema.
  3. Tente correr com --trace-warnings habilitado, por exemplo, rm -rf node_modules/; NODE_OPTIONS=--trace-warnings yarn :
(node:4672) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
    at showFlaggedDeprecation (buffer.js:159:11)
    at new Buffer (buffer.js:174:3)
    at Object.<anonymous> (/usr/share/yarn/lib/cli.js:68827:20)
    at __webpack_require__ (/usr/share/yarn/lib/cli.js:22:30)
    at Object.module.exports.module.exports (/usr/share/yarn/lib/cli.js:129944:17)
    at __webpack_require__ (/usr/share/yarn/lib/cli.js:22:30)
    at Object.module.exports.module.exports.id (/usr/share/yarn/lib/cli.js:107711:12)
    at __webpack_require__ (/usr/share/yarn/lib/cli.js:22:30)
    at Object.module.exports.Object.defineProperty.value (/usr/share/yarn/lib/cli.js:62536:14)
    at __webpack_require__ (/usr/share/yarn/lib/cli.js:22:30)

Nesse ponto, eu estava um pouco perplexo. Abrindo /usr/share/yarn/lib/cli.js espiando perto da linha 68827, vi o seguinte:

/* 285 */
/***/ (function(module, exports, __webpack_require__) {

var stream = __webpack_require__(69)
var eos = __webpack_require__(549)
var inherits = __webpack_require__(59)
var shift = __webpack_require__(741)

var SIGNAL_FLUSH = new Buffer([0])

var onuncork = function(self, fn) {
  if (self._corked) self.once('uncork', fn)
  else fn()
}

var destroyer = function(self, end) {
  return function(err) {
    if (err) self.destroy(err.message === 'premature close' ? null : err)
    else if (end && !self._ended) self.end()
  }
}

Pesquisar no GitHub por algumas das partes de aparência mais exclusivas deste código me levou a descobrir que ele vem de duplexify antes da v3.5.4. Em seguida, executei yarn why duplexify e descobri que uma das minhas dependências o estava usando. No entanto, ele estava usando a v3.6.0, o que não deveria ter nenhum problema. Tentei adicionar esse pacote / versão ao meu projeto vazio / mínimo e executar novamente yarn . Na verdade, funcionou bem: sem avisos. Além disso, isso não explica por que o rastreamento mostrou um script webpack associado a yarn .

Embora eu não tenha certeza de como fiz isso, uma vez recebi uma linha diferente no rastreamento do aviso e ela apontava para o mesmo arquivo cli.js do webpack, mas o código dentro era de sshpk (antes de # 175758a).

Percebendo que new Buffer aparece no código na compilação noturna do JS autônomo do yarn, acabei desistindo por agora, esperando que a mensagem sumisse por conta própria depois que o yarn fosse atualizado no futuro.

@jacobq Obrigado por investigar isso! Não sou especialista nisso - literalmente acabei de encontrar esse problema - mas depois de ler e reler suas descobertas, parece que o que você está dizendo é que o Yarn está incluindo uma versão antiga de duplexify em seu código CLI? Isso é correto?

Ainda vendo isso também.

Eu fui para https://nodejs.org/ agora mesmo e descobri que a versão mais recente já é 10.5 👀
Enquanto isso, meus colegas e eu ainda estamos no 8.x porque este problema ainda está aberto 😅 Tão ansiosos para explorar o que há de novo no 10.x! 🚀 🙏

@kachkaev Não deixe que este aviso o impeça! :sorriso:

@mcmire Ele parece que maneira para mim. Suspeito que eles só precisam executar yarn upgrade ... para atualizar o arquivo de bloqueio.

@kachkaev 8.x ainda é a versão mais recente do LTS até este outono , então não há vergonha em usá-lo, especialmente na produção. Além disso, como @teohhanhui mencionou, isso é apenas um aviso, portanto, não "quebrado", exceto nos casos em que a saída está sendo fortemente acoplada a alguma aplicação / lógica.

@jacobq já existem alguns pacotes que requerem um nó> = 9 para funcionar.

Eu também estava usando o nó 8 por causa desse aviso, mas agora sou forçado a vê-lo toda vez que uso o fio, o que é realmente decepcionante. Isso me faz pensar em usar npm, mas eu adoro yarn e não quero voltar atrás. Tentar ignorar esse aviso todos os dias é triste. 😢

Alguém já descobriu uma solução para esse problema? É tão irritante olhar cada vez que executo um comando do yarn

+1

yarn install v1.7.0
info Nenhum lockfile encontrado.
[1/4] Resolvendo pacotes ...
⠁ (nó: 12916) [DEP0005] DeprecationWarning: Buffer () está obsoleto devido a problemas de segurança e usabilidade. Use os métodos Buffer.alloc (), Buffer.allocUnsafe () ou Buffer.from ().
em showFlaggedDeprecation (buffer.js: 159: 11)
no novo Buffer (buffer.js: 174: 3)
em Object.module.exports.module.exports (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 4105: 6)
em __webpack_require__ (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 22: 30)
em Object.module.exports.module.exports (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 4228: 12)
em __webpack_require__ (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 22: 30)
em Object.module.exports.module.exports (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 56449: 11)
em __webpack_require__ (C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 22: 30)
em Object.(C: \ Arquivos de programas (x86) \ Yarn \ lib \ cli.js: 43234: 13)

Eu também estava sofrendo com isso no meu OSX, mas um:

yarn global add yarn

Pareceu resolver ... Será que a versão do homebrew está de alguma forma danificada ... 🤔

@carddamom Isso realmente resolveu ou talvez o problema simplesmente desapareceu porque você já o executou uma vez? (Ainda vejo new Buffer aparecendo 134 vezes nas noites de 7/6 .) Estou curioso: se você excluir node_modules e executar yarn novamente, verá o aviso novamente?

Isso também corrigiu este problema para mim:

image

Tirei o fio que foi instalado com o Homebrew e reinstalei-o globalmente com o npm. Não vi mais esse problema e alguns outros erros relacionados ao gyp também desapareceram.

Eu me pergunto se a versão do homebrew está de alguma forma danificada ... 🤔

Eu definitivamente apontaria meu dedo para o Homebrew agora.

@jacobq Para mim, não havia node_modules para desinstalar, já que estava usando "yarn global", como uma anedota, também tentei vincular novamente o pacote usando homebrew e o erro reapareceu, então ele confirma isso ...

O motivo de você estar vendo apenas o aviso do lançamento tar.gz e do Homebrew ( que apenas instala o lançamento tar.gz ) é porque o Node não emite o aviso de depreciação quando o módulo que chamou new Buffer está dentro de um node_modules diretório.

Então, quando você instala via homebrew, o executável do yarn estará em:

/usr/local/bin/yarn

Mas quando você instala via npm, será em um caminho como (estou usando nvm aqui):

~/.nvm/versions/node/v10.6.0/lib/node_modules/yarn/bin/yarn

O código é exatamente o mesmo, a única diferença é que, como o npm o instalou em um diretório que contém node_modules ele não emite atualmente o aviso.

Consulte isInsideNodeModules chamado dentro do módulo de buffer nativo para referência.

Ao que parece, lib/cli.js ainda contém uma série de chamadas para new Buffer . É tudo um grande pacote de webpack, portanto, não sei de quais bibliotecas eles vêm, mas um comentário acima parece ter identificado o pacote.

Sim, apenas confirmando que ainda está acontecendo para mim com a versão do repositório Debian / Ubuntu (presumivelmente pelos motivos listados acima), certamente não é nada específico do Homebrew.

Se demorar um pouco para atualizar os usos de new Buffer nas várias dependências, talvez valha a pena encontrar uma maneira de apenas silenciar esse aviso específico por enquanto. Do meu lado, adicionar a bandeira --no-deprecation no local apropriado em /usr/bin/yarn funciona, mas parece um pouco complicado e pesado.

Editar: você também pode executar fios como NODE_OPTIONS=--no-deprecation yarn que funciona. Acho que vou definir isso como um alias.

@jacobq ... pela sugestão dos vossos rapazes, retirei os meus comentários, deixei apenas o dele, parece curto! Não vou adicionar mais.
...Feito...

Como solução temporária, estou usando um apelido como @noinkling sugerido.

Para aqueles que usam fish :

function yarn
  env NODE_OPTIONS=--no-deprecation yarn $argv
end

Isso ainda está acontecendo no 1.9.2 rc que contém 2f4bba1 (?), Por exemplo

yarn install v1.9.2
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
[----------------------------------------------------------------------] 0/1820
(node:1936) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
[4/5] 🔗  Linking dependencies...

Usando o nó 10.6, macOS 10.13.6.

@vieira Sim, infelizmente ainda existem alguns outros departamentos que precisam ser atualizados para resolver isso completamente. Veja meu comentário aqui para uma lista deles. (Alguns estão esperando por RP, então você pode ajudar contribuindo com esses esforços ou pelo menos dando uma reação +1).

tendo o mesmo problema
nó v10.7.0, yarn 1.9.2

node:67668) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=4 <=9".

@bogdansoare parece que você está usando um módulo incompatível em seu projeto. Tente yarn why upath então remova / atualize a parte que o está trazendo para eliminar o erro.

Os comentários do PS + 1 / eu também são geralmente desaprovados. Em vez disso, use os botões de reação.

@jacobq Este problema do GitHub foi

@corshamax Este problema específico foi corrigido porque atualizamos nosso código para parar de usar a estrutura problemática. O aviso ainda aparece porque algumas de nossas dependências ainda o estão usando, mas esse é um problema diferente (com o mesmo resultado, infelizmente) que deve ser relatado aos projetos relevantes (e, em seguida, a nós quando uma versão corrigida for feita para que possamos atualizar a dependência afetada).

E, como para tudo, agradecemos as solicitações pull, então se você descobrir que algo pode ser consertado, apenas abra um e faremos a fusão para o próximo lançamento. @jacobq fez um trabalho incrível listando as dependências que podem precisar ser atualizadas, esse é um bom ponto de partida: https://github.com/yarnpkg/yarn/pull/5934#issuecomment -406346724

Vejo esse problema com o node v10.8.0 e yarn v1.9.4.

Parece que todos os PRs mencionados em https://github.com/yarnpkg/yarn/pull/5934#issuecomment -406346724 foram mesclados. Espero que isso signifique que possamos ver uma solução para isso em breve.

@vrobinson Sim, eles devem ser corrigidos por https://github.com/yarnpkg/yarn/pull/6208 - Você pode ver isso pesquisando o JS autônomo por new Buffer e observando que ele só aparece em substitutos e comentários. Tenha paciência: smile_cat:

Atualização: Parece que acabou de pousar: tada: então fique atento para a próxima noite. A todos que ajudaram a fazer isso acontecer,: bowing_man: obrigado: pray :!

Recebi este erro, foi resolvido?

@ rof20004 : point_up: (logo acima do seu comentário) . PR foi mesclado, então agora está "fixo" no ramo master do código-fonte. No entanto, você continuará a ver este aviso com o Nó 10 até (1) uma nova versão ser lançada e (2) você atualizar para essa versão.

@jacobq estou usando o pacote debian, preciso esperar até o novo pacote e então '-'.

Obrigado :)

@ rof20004 Você deve poder começar a usá-lo amanhã, se quiser, apenas certifique-se de ter apt apontando para o noturno:
https://yarnpkg.com/en/docs/install#debian -nightly

@jacobq, então vamos ver este problema finalmente resolvido de uma vez por todas com [email protected] , correto?

Provavelmente não será um lançamento de patch, mais como 1.10

Eu tenho o mesmo problema.
$ yarn install
node:39) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. error An unexpected error occurred: "https://registry.yarnpkg.com/axios/-/axios-0.18.0.tgz: getaddrinfo EADDRNOTAVAIL registry.yarnpkg.com registry.yarnpkg.com:443". info If you think this is a bug, please open a bug report with the information provided in "/app/yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
/app $ node -v v10.10.0 /app $ yarn -v 1.9.4 /app $

alguem tem a solução?

@ codestart123 leu o tópico, eles disseram que foi corrigido todas as noites, mas ainda não foi lançado.

@ codestart123 O erro que você mencionou não é causado por esse problema (você pode ignorar o aviso de

error An unexpected error occurred: "https://registry.yarnpkg.com/axios/-/axios-0.18.0.tgz: getaddrinfo EADDRNOTAVAIL registry.yarnpkg.com registry.yarnpkg.com:443"

EADDRNOTAVAIL é um erro relacionado à rede (erro: endereço não disponível). Tente executar ping registry.yarnpkg.com para confirmar que seu sistema pode resolver o nome e alcançar o host.

Já foi corrigido?

@ ryanzhu1024 foi corrigido no 1.10.0, lançado há alguns dias 👍

Aguardando atualização da versão do fio do nó.

Não posso acreditar que este aviso irritante finalmente se foi. Obrigado :)

Hooraaaay 🙌 🎉 🍾

@goktugyil A pergunta que você vinculou não faz qualquer menção a yarn . Se você estiver usando yarn, certifique-se de ter a versão mais recente (atualmente 1.12.3 ). Se você não estiver usando yarn , não faça postagem cruzada aqui. StackOverflow é um bom lugar para fazer perguntas gerais sobre programação e https://github.com/nodejs/help é um bom lugar para fazer perguntas sobre o Node. https://github.com/yarnpkg/yarn/issues é para solicitações de recursos e problemas relacionados ao yarn (não para suporte de desenvolvimento geral / perguntas).

@arcanis / @BYK / @imsnif Importa-se de bloquear este tópico? Este problema foi corrigido no yarn e em suas dependências por um tempo, e não acho que uma discussão mais aprofundada aqui irá beneficiar ninguém.

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