Yarn: Replace use of deprecated/unsafe new Buffer constructor

[johnmuhl]

What is the current behavior?

yarn uses deprecated new Buffer() constructor and causes deprecation warnings when run with 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];

What is the expected behavior?

yarn should not use deprecated/unsafe Buffer constructor. According to the deprecation warning new Buffer() should be replaced with one of Buffer.alloc(), Buffer.allocUnsafe() or Buffer.from(); the safe-buffer package is another option.

Please mention your node.js, yarn and operating system version.

$ 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

[malonehedges]

Getting this same warning on macOS. I believe #5704 is a duplicate of this.

[felixrabe]

As a workaround for now, I've created a ~/bin/node script that comes before (Homebrew-installed) /usr/local/bin/node in my $PATH:

#!/bin/bash

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

[marvinhagemeister]

FYI: Just went through yarn's dependencies and there are two which still call new Buffer():

• tar-stream (fixed, but we still depend on an older version)
• v8-compile-cache (not fixed)

We will likely need to update those.

[jjhesk]

@martinstuecklschwaiger when is the fix done???

[fengerzh]

@marvinhagemeister v8-compile-cache just released 2.0.0 version, which fixed the bug. Hope we can soon update to new version.

[marvinhagemeister]

@fengerzh @imsnif already committed the new version to master https://github.com/yarnpkg/yarn/commit/546a1576edbf701021ce65e3dd8daff267083f52 🎉

[simeg]

When do you plan on releasing a new version with this fix? I couldn't find any info on how you deal with releases.

I see the high-priority label was used on this issue, doesn't that also mean that you want to push the fix ASAP? Not only fixing it ASAP.

EDIT: Didn't mean to sound pushy or demanding in any way, I'm just curious how you approach these high-priority issues. The reason I asked was because it's annoying to get a warning about this for every new shell instance I start.

[piotr-cz]

This warning started popping up after I've upgraded from node v0.9.x to v0.10.1

[oshalygin]

@piotr-cz you mean v10.1, 0.10 is pretty ancient.

[piotr-cz]

Thanks, I meant that the warning started popping up after upgrade from v9.x to v10.1.0

[Gurenax]

Still getting this warning with 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.

My node.js, yarn and operating system version

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

[intensr]

Any progress here? We would really like to use node 10 within our project without any workaround 🔥

[teohhanhui]

It's just a warning. Why would it prevent you from using it?

[jasperf]

Same issue here and it causes my Roots Sage theme not to compile failing it to deploy. See also https://discourse.roots.io/t/buffer-deprecated-yarn-warning/12525

[jeffs]

@teohhanhui Long-lived warnings are problematic because they obscure other, more useful warnings: It would be unreasonable to expect developers to look through all warnings on every build, and mentally discount only the "acceptable" ones. It's therefore common (and entirely reasonable) to treat all warnings as errors. This isn't a complaint about yarn, which is great; but the phrase "It's just a warning" raises loud mental alarm bells.

[kylecordes]

There are large, extremely prosperous software/etc firms, brand names we all know, who have companywide rules like: treat warnings as errors or delete them, but never spend human labor looking through warning lists routinely. For the reason mentioned above.

This not to say this is perfect advice replies everywhere, but it is not uncommon and pretty well demonstrated as workable and valuable.

[teohhanhui]

If you're going to treat all warnings as errors, wouldn't you have a way to ignore / whitelist warnings? But anyway, I don't see how it's yarn's fault that you choose to do that. yarn is not broken in this case.

[BYK]

Sorry to do this but I have to lock this issue since people don't seem to be reading earlier comments. Here's the summary:

• This issue has not been resolved yet (as of Yarn 1.6.0)
• Yes, we as the yarn team are aware and are working hard to fix this and release a new version. You can follow #5769 to see the progress (please, please do not use that PR as another discussion forum for this)
• We have discovered an issue regarding symlinks on Windows when using Yarn on Node 10 which may cause installs to stall with an infinite recursion. This issue is also being addressed in #5769

I apologize on behalf of the whole Yarn team for the issue and the delay.

[BYK]

Update: the above-mentioned PR is now merged. We'll release a new version as soon as possible.

[BYK]

Version 1.7.0 with the fix just went live. Thanks for your patience!

[intensr]

@teohhanhui were using it in a single repository within a lerna stack, so yarn warning kill of the lerna process (yes might be more of a lerna setting thing here, but cleaning warnings also fixes the issue for us)
@BYK thanks byk for your efford

[ezzatron]

@BYK I'm still seeing Buffer warnings with 1.7.0 from 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)

[AlexanderOMara]

@ezzatron Same here.

[Gurenax]

@ezzatron @AlexanderOMara
I think the warning only appears after executing yarn for the first time after the brew update. Upon executing yarn the second time, the warning is gone for me.

Here's the current state of my machine:

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

Here's my terminal log

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

[Justkant]

Hi, I'm still having a DeprecationWarning when doing a 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.

[rpellerin]

Run yarn upgrade, it's likely you have a dependency on upath due to some package and still have an version installed.

[Justkant]

@rpellerin Thanks but upath is already up to date
Even after a yarn upgrade I still get the same warning but not at the same moment as the 1.6 version
Also after some tests, it's not limited to 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.

Tested with node v10.1.0 & v10.2.0, I'm on OSX and use brew to install yarn (using --without-node param)

[rpellerin]

@Justkant can you run NODE_OPTIONS=--trace-warnings yarn? This will tell you which package triggers the warning.
Then you can run yarn why <package>. I'll reply accordingly.

[wishpinebetter]

Yes, It was solved after upgrade to 1.7.0
Thanks @BYK

[Justkant]

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

But why would I do a yarn why <package> ? The warning is not linked to my local packages but only to yarn itself, no ?

[rpellerin]

I thought it'd be because of a package. Try using yarn from npm?
npm i -g yarn

[Justkant]

Using yarn from npm seems to work correctly

[kbd]

yarn shows no warning for me but yarn outdated does.

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

[pfcodes]

Heads up: It appears that the old buffer constructor is still used for the global CLI. I still get the error message when dealing with yarn global commands. @BYK

[BYK]

Ack! Thanks for the detailed reports. I'll look into this today.

[BYK]

Okay, the offending package is sshpk which is required by http-signature which is required by request. There is a PR for a fix but it doesn't seem to be getting any love. Anyone know someone at Joyent to help us?

[mikestepanov]

Still issue as of yarn 1.7.0 with node > 10.0.0

Fixed issue by uninstalling node that came with yarn and installed stable 8.11.2 from https://nodejs.org/en/

[kbd]

Fixed issue by uninstalling node that came with yarn and installed [old version]...

It's not really "fixing" if you just go back to a version before it was deprecated for being unsafe.

[pluma]

The issue @mikestepanov linked seems to have been resolved. The offending file now uses Buffer.from:

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

This seems to have been released as 1.14.2, which matches http-signature's required version range.

IOW it looks like simply updating yarn's lockfile and cutting a new release should fix this.

[mcmatan]

The only thing that helped was deleting yarn.lock file, as @pluma said

[pluma]

FWIW this bug broke getstorybook for me because it tried to parse stderr, which the warnings are printed to. Not sure if storybook-cli has been updated to work around this but worth mentioning this is more than a cosmetic problem.

[vladshcherbin]

@BYK The situation with this bug is very sad for developers all over the world, can you publish a fixed version of yarn (1.7.1 or smth) with bumped version of the package inside as proposed in https://github.com/yarnpkg/yarn/issues/5477#issuecomment-396903361 please? 🙏

[jacobq]

This commit (from last month) looks like it's supposed to close this issue, but I am still seeing this with node 10.5.0 & yarn 1.9.0-20180621.1511 (nightly). Like @Gurenax's situation, the warning only appears during the initial run for me (delete node_modules then run yarn). In case it's helpful for others, I've included some notes related to what I found/did below. It seems like yarn's dependencies are out of date as one can see new Buffer calls in the current nightly standalone JS builds.

1. Check with an empty/minimal project to see if the warning persists. (e.g. mkdir empty-project; cd empty-project; npm init empty-project; yarn).
2. If the warning appears there then you may need to upgrade yarn (try latest rc: v1.8 though v1.7.0 was supposed to fix it). In my case it didn't happen in the minimal case, so I had to dig deeper. First I ran yarn upgrade but that didn't seem to fix it.
3. Try running with --trace-warnings enabled, e.g. 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)

At this point I was a bit stumped. Opening up /usr/share/yarn/lib/cli.js peeking near line 68827 I saw this:

/* 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()
  }
}

Searching GitHub for some of the more unique-looking parts of this code led me to discover that it comes from duplexify prior to v3.5.4. Next I ran yarn why duplexify and found that one of my dependencies was using it. However, it was using v3.6.0, which shouldn't have any problem. I tried adding that package/version to my empty/minimal project and re-running yarn. Indeed it worked fine: no warnings. Plus that doesn't explain why the trace showed a webpack'd script associated with yarn.

Although I'm not sure how I did it, one time I got a different line in the trace for the warning, and it pointed to that same webpack'd cli.js file, but the code inside was from sshpk (prior to #175758a).

Realizing that new Buffer appears in the code in yarn's standalone JS nightly build, I eventually gave up for now, hoping that the message will go away on its own after yarn is updated in the future.

[mcmire]

@jacobq Thanks for looking into this! I'm no expert on this -- I literally just came across this issue -- but after reading and re-reading your findings it sounds like what you're saying is that Yarn is including an old version of duplexify in its CLI code? Is that accurate?

[damianobarbati]

Still seeing this as well.

[kachkaev]

I went to https://nodejs.org/ just now and discovered that the latest version is already 10.5 👀
Meanwhile, my colleagues and I are still on 8.x because this issue is still open 😅 So keen to explore what's new in 10.x! 🚀 🙏

[teohhanhui]

@kachkaev Don't let this warning stop you! :smile:

[jacobq]

@mcmire It looks that way to me. I suspect they just need to run yarn upgrade ... to freshen up the lock file.

@kachkaev 8.x is still the latest LTS version until this fall, so there's no shame in using it, especially in production. Also, as @teohhanhui mentioned, this is just a warning so it's not "broken" except in cases where the output is being tightly coupled to some application/logic.

[vladshcherbin]

@jacobq there are already some packages that require node >= 9 in order to work.

I was also using node 8 because of this warning but now I'm forced to see it every time I use yarn which is really disappointing. It makes me think about using npm instead but I love yarn a lot and don't want to switch back. Trying to ignore this warning every day is sad. 😢

[milkdazombie]

Has anyone figured out a solution to this issue yet? It's so annoying to look at every time I run a yarn command

[columnistdc]

+1

yarn install v1.7.0
info No lockfile found.
[1/4] Resolving packages...
⠁ (node:12916) [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 (C:\Program Files (x86)\Yarn\lib\cli.js:4105:6)
at __webpack_require__ (C:\Program Files (x86)\Yarn\lib\cli.js:22:30)
at Object.module.exports.module.exports (C:\Program Files (x86)\Yarn\lib\cli.js:4228:12)
at __webpack_require__ (C:\Program Files (x86)\Yarn\lib\cli.js:22:30)
at Object.module.exports.module.exports (C:\Program Files (x86)\Yarn\lib\cli.js:56449:11)
at __webpack_require__ (C:\Program Files (x86)\Yarn\lib\cli.js:22:30)
at Object. (C:\Program Files (x86)\Yarn\lib\cli.js:43234:13)

[carddamom]

I was also suffering from this on my OSX, but an:

yarn global add yarn

Seemed to solve it... I wonder if the version on homebrew is somehow broken... 🤔

[jacobq]

@carddamom Did that really solve it or perhaps did the problem just disappear because you had already run it once? (I still see new Buffer appearing 134 times in the 7/6 nightly.) I am curious: if you delete node_modules and run yarn again do you see the warning again?

[qkdreyer]

This fixed this issue for me aswell :

[tlaak]

I removed yarn which was installed with Homebrew and reinstalled it globally with npm. Didn't see this issue anymore and some other gyp related errors were also gone.

I wonder if the version on homebrew is somehow broken... 🤔

I'd definitely point my finger at Homebrew now.

[carddamom]

@jacobq For me there was no node_modules to uninstall, since I was using "yarn global", as a anecdote I've also tried to relink the package using homebrew and the error reappeared, so it further confirms this...

[AlexanderOMara]

The reason you are only seeing the warning from the tar.gz release and Homebrew (which just installs the tar.gz release) is because Node does not emit the deprecation warning when the module that called new Buffer is inside a node_modules directory.

So when you install via homebrew, the yarn executable will be at:

/usr/local/bin/yarn

But when you install via npm it will be at a path like (I'm using nvm here):

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

The code is exactly the same, the only difference is that because npm installed it to a directory containing node_modules it does not currently emit the warning.

See isInsideNodeModules called inside the native buffer module for reference.

From the look of things lib/cli.js still contains a number of calls to new Buffer. It's all one big webpack bundle though so I don't know what libraries they come from, but an above comment seems to have identified the package.

[noinkling]

Yeah just confirming that it's still happening for me with the Debian/Ubuntu repository version (presumably for the reasons listed above), it's certainly nothing specific to Homebrew.

If it's gonna take a while to update uses of new Buffer in the various dependencies, maybe it's worth finding a way to just silence that particular warning for now. On my side, adding the --no-deprecation flag in the appropriate place in /usr/bin/yarn works, but feels a bit hacky and heavy-handed.

Edit: you can also run yarn like NODE_OPTIONS=--no-deprecation yarn which works. I think I'm gonna set that as an alias.

[yarcowang]

@jacobq ... for your guys' suggestion, I removed my comments, only left his one, then it seems short! Not going to add more.
...Done...

[azdanov]

As a temporary solution I'm using an alias as @noinkling suggested.

For those using fish:

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

[vieira]

This is still happening on 1.9.2 rc that contains 2f4bba1 (?), e.g.

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

Using node 10.6, macOS 10.13.6.

[jacobq]

@vieira Yes, unfortunately there are still some other deps that need to be upgraded to completely resolve this. See my comment here for a list of them. (Some are waiting on PRs so you might be able to help by contributing to those efforts or at least giving a +1 reaction).

[bogdansoare]

having the same issue
node 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".

[jacobq]

@bogdansoare looks like you are using an incompatible module in your project. Try yarn why upath then remove / update the part that's bringing it in to eliminate the error.

P.S. +1/me too comments are generally frowned upon. Please use the reaction buttons instead.

[corshamax]

@jacobq This GitHub issue was closed, but I'm still seeing the issue in the latest 1.9.2 release. I understand that the issue is caused by downstream dependencies, but it isn't clear whether the Yarn team believes this is fixed. Is this supposed to be fixed, or is this closed because the solution is to disable the warning? Suppressing the warning is not a fix for me and my team, as disabling security warnings is unacceptable in my team's context.

[arcanis]

@corshamax This specific issue is fixed because we updated our code to stop using the problematic structure. The warning still appears because some of our dependencies are still using it, but that's a different issue (with the same outcome, unfortunately) that should be reported to the relevant projects (and then to us once a fixed release is made so that we can upgrade the affected dependency).

And as for everything, we welcome pull requests, so if you find out something can be fixed, just open one and we'll make sure to merge it for the next release. @jacobq made an awesome work by listing dependencies that might need to be updated, that's a good starting point: https://github.com/yarnpkg/yarn/pull/5934#issuecomment-406346724

[vrobinson]

I see this issue with node v10.8.0 and yarn v1.9.4.

It looks like all the PRs mentioned in https://github.com/yarnpkg/yarn/pull/5934#issuecomment-406346724 have been merged. I hope that means we can see a fix for this very soon.

[jacobq]

@vrobinson Yes, they should be fixed by https://github.com/yarnpkg/yarn/pull/6208 -- You can see this by searching the standalone JS for new Buffer and observing that it only appears in fallbacks and comments. Have patience :smile_cat:

Update: Looks like it just landed :tada: so watch for the next nightly. To everyone who helped make this happen, :bowing_man: thank you :pray:!

[rof20004]

I got this error, was this solved?

[jacobq]

@rof20004 :point_up:(right above your comment). PR has merged, so it is now "fixed" on the master branch of the source code. However, you'll continue to see this warning with Node 10 until (1) a new version is released and (2) you upgrade to that version.

[rof20004]

@jacobq I am using debian package, I need to wait until the new package then '-'.

Thanks :)

[jacobq]

@rof20004 You should be able to start using it tomorrow, if you want, just make sure you have apt pointing to the nightly:
https://yarnpkg.com/en/docs/install#debian-nightly

[damianobarbati]

@jacobq so we're going to see this finally issue finally resolved once for all with [email protected], correct?

[arcanis]

Probably won't be a patch release, more like 1.10

[josuedjh3]

I have the same problem.
$ 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 $

[josuedjh3]

someone has the solution?

[kbd]

@codestart123 read the thread, they said it's fixed in nightly but not released yet.

[jacobq]

@codestart123 The error you mentioned is not caused by this issue (you can ignore the deprecation warning):

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 is a network-related error (error: address not available). Try running ping registry.yarnpkg.com to confirm that your system can resolve the name and reach the host.

[RyanZhu1024]

Has it been fixed yet?

[wopian]

@ryanzhu1024 it was fixed in 1.10.0, released a few days ago 👍

[iofu728]

Waiting node upgrade yarn version.

[vladshcherbin]

Can't believe this annoying warning is finally gone. Thank you :)

Hooraaaay 🙌 🎉 🍾

[goktugyil]

I have a similar problem here, any ideas: https://stackoverflow.com/questions/53201124/how-to-find-source-of-a-problem-inside-a-npm-package-node36378-dep0005-dep

[jacobq]

@goktugyil The question you linked does not make any mention of yarn. If you are using yarn, please make sure you have the latest version (currently 1.12.3). If you are not using yarn please do not cross-post here. StackOverflow is a good place for asking general programming questions, and https://github.com/nodejs/help is a good place to go for Node questions. https://github.com/yarnpkg/yarn/issues is for feature requests and problems related to yarn (not for general development support/questions).

@arcanis / @BYK / @imsnif Would you mind locking this thread? This problem has been fixed in yarn and its dependencies for a while now, and I don't think further discussion here will benefit anyone.