Change:
Issue Type: <bBug</bI have verified that the warning does NOT occur in version 1.36.0 in which similar issue was fixed. VS Code version: Code 1.39.0 (, 2019-10-09T06:58:04.439Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ vscode-html-css0.2.3 devinsights2019.10.11-1 cpptools0.25.1 vscode-typescript-tslint-plugin1.2.2 debugger-for-chrome4.12.0 </details<!-- generated by issue reporter --
40.2 still has this error as well when installing following extensions: , , , , vsciot-, vsciot-, eamodio.gitlens, and a few others. It does appear to be a built-in problem within vscode when installing extensions via cli.
I am not able to see these warning when running from sources. Also I have not changed any node dependencies from 1.36. I was clue less from where these warnings are coming from. Any help would be appreciated.
maybe try this: configure run out of sources From now on you should see stacktraces where the offender is coming from. Alternatively, if we know the extension that is causing this, try to find the deprecated usages of the Buffer constructor.
Tried this and did not help.
Yes running out of source did not work. Tried on insiders and I can see the error now. Thanks.
This is coming from module. Filed issues
am having the same issue but on usage however it show on first run only.
It appears on the maintainer has no interest in fixing this. Despite nearly 9 million weekly downloads. On replacing with a fork has been proposed as a fix but it hasn't been merged. Sigh...
Any update? This is still happening. I see the deprecation warning every time the starts. I also see the issue reported here when installing extensions. It's really annoying. Edit: I've managed to at least silence the error when starting the for extension development with:
My problem is simple but related: In the warning, it is said: But when i run in the terminal, there's a new warning Did I do something wrong?
see on how to use the option.
Thank you I'll try it tomorrow.
The same problem still exists in the latest 1.62.2 version. I just double-clicked the VSCode icon to open it, new a terminal, and the Buffer() error was printed in the Log(Window) view. The VSCode I opened for testing is a fresh 1.62.2 portable VSCode with 0 extension installed. (The 1.62.2 installation VSCode showed the same error message as well) [2021-11-12 10:41:06.693] [renderer1] [info] Starting extension host with pid . [2021-11-12 10:41:06.693] [renderer1] [info] [LocalProcessExtensionHost]: () took 1029 ms. [2021-11-12 10:41:07.071] [renderer1] [error] [Extension Host] (node:) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the (), Buffer.allocUnsafe(), or () methods instead. (Use to show where the warning was created)
got same issue
npm 8 allows for , so maybe that's an option if the original author doesn't respond and it's too time-consuming to replace the immediate dependency causing the trouble. We could set it to a fork with a fix.
OS: Windows 10 21H2 Version: VS Code 1.66 x64 system installation Module: ms-vcode.PowerShell-2021- Same error: (node:7368) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the (), Buffer.allocUnsafe(), or () methods instead. This ever going to get fixed? Pretty annoying trying to script/deploy VS Code + extensions in air-gapped environments when you can't even install Microsoft developed and maintained extensions like PowerShell. The error pauses the CMD window and requires input to continue the extension's installation. I'm sure I can script around it, but seriously... It's been present in numerous major builds of VS Code, since at least 1.39. I can say for certain it's been present in 1.40 - 1.66.
It seems that just exporting one of , , and could mute the annoying deprecation warning now. Here is my installation script
Almost 3 years and every extension developer still has to watch these confusing deprecation watchings. Hiding them with is a very dangerous thing to do as that might prevent them from spotting other similar problems that they could fix.
might it be an idea to consider replacements for these modules? They both appear to be stale and not had any code changes since prior to this issue being opened 2.5 years ago. And short of that, could this issue at least be tagged with some indicate as to why it appears to have had no movement (such as that it's a dependency issue, and not a vscode issue)?
That's a good idea. Will look into that. Thanks, upstream-issue-linked label
I am trying to install 23 extensions so that I have similar work environments without VPN (Windows) and with VPN (Linux). I have observed that all 23 extensions install fine on Windows with But I can only install 3 extensions on Linux with
your issue is unlikely to be related to this one. More likely the extensions require a more recent version of VS Code than the 1.63.2 your Linux environment has.
100% agree that my company's Linux version is woefully behind, and many of the issues are related to that. But, it has definitely run into the deprecated buffer() error as well. I was hoping these 2 clues would be helpful: Windows vs. Linux and v1.63.2 vs 1.68.1. If more details would be helpful (e.g., which extension fail with "buffer() deprecated" on 1.63.2 Linux), let me know. My company's connection to extensions on Linux is also woefully slow. It would help if there was a way to download all the .vsix files that you were interested in and try them on CLI.
AFAIK the deprecation warning is only a warning, and only appears when installing using the CLI or when developing extensions. I wouldn't expect any extension to fail because of it. More likely the latest versions of some extension won't install on your older VS Code version.
Sure, but what if you're in an enterprise environment and want to push out Visual Studio Code + XYZ extensions to 100s or 1000s of workstations and regularly update said extensions. From memory, the warning output also pauses the installation of extensions until the user inputs any key into the console window.... All I want is the ability to install extensions via CLI without errors/warnings/additional console windows popping up. That's hardly an unreasonable request.
Is it possible that this warning is happening only when you have as a devDependencies in the extension? Those problematic packages are used by the vsce. Our code is not really using any package that depends on nor .
Issue detected again in the following version: Here are the Windows Terminal traces of my script executing the command:
Same as above:
On Windows:

Discussion:
"vscode-oniguruma": "1.7.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "yauzl": "^2.9.2", </del> <ins> "yauzl": "^3.0.0", </ins> "yazl": "^2.4.3" }, "devDependencies": {

"@types/wicg-file-system-access": "^2020.9.6", "@types/windows-foreground-love": "^0.3.0", "@types/winreg": "^1.2.30", <del> "@types/yauzl": "^2.9.1", </del> <ins> "@types/yauzl": "^2.10.0", </ins> "@types/yazl": "^2.4.2", "@typescript-eslint/eslint-plugin": "^5.57.0", "@typescript-eslint/experimental-utils": "^5.57.0",

"vscode-oniguruma": "1.7.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "yauzl": "^2.9.2", </del> <ins> "yauzl": "^3.0.0", </ins> "yazl": "^2.4.3" } }

buffer-crc32 "~0.2.3" fd-slicer "~1.1.0" <ins> yauzl@^3.0.0: version "3.1.1" resolved "https://registry.yarnpkg.com/yauzl/-/yauzl-3.1.1.tgz#d85503cc34933c0bcb3646ee2b97afedbebe32e7" integrity sha512-MPxA7oN5cvGV0wzfkeHKF2/+Q4TkMpHSWGRy/96I4Cozljmx0ph91+Muxh6HegEtDC4GftJ8qYDE51vghFiEYA== dependencies: buffer-crc32 "~0.2.3" pend "~1.2.0" </ins> yazl@^2.4.3: version "2.4.3" resolved "https://registry.yarnpkg.com/yazl/-/yazl-2.4.3.tgz#ec26e5cc87d5601b9df8432dbdd3cd2e5173a071"

const { open } = await import('yauzl'); return new Promise<ZipFile>((resolve, reject) => { <del> open(zipFile, lazy ? { lazyEntries: true } : undefined!, (error?: Error, zipfile?: ZipFile) => { </del> <ins> open(zipFile, lazy ? { lazyEntries: true } : undefined!, (error: Error | null, zipfile?: ZipFile) => { </ins> if (error) { reject(toExtractError(error)); } else {

function openZipStream(zipFile: ZipFile, entry: Entry): Promise<Readable> { return new Promise<Readable>((resolve, reject) => { <del> zipFile.openReadStream(entry, (error?: Error, stream?: Readable) => { </del> <ins> zipFile.openReadStream(entry, (error: Error | null, stream?: Readable) => { </ins> if (error) { reject(toExtractError(error)); } else {

resolved "https://registry.yarnpkg.com/@types/winreg/-/winreg-1.2.30.tgz#91d6710e536d345b9c9b017c574cf6a8da64c518" integrity sha1-kdZxDlNtNFucmwF8V0z2qNpkxRg= <ins> "@types/yauzl@^2.10.0": version "2.10.3" resolved "https://registry.yarnpkg.com/@types/yauzl/-/yauzl-2.10.3.tgz#e9b2808b4f109504a03cda958259876f61017999" integrity sha512-oJoftv0LSuaDZE3Le4DbKX+KS9G36NzOeSap90UIK0yMA/NhKJhqlSGtNDORNRaIbQfzjXDrQa0ytJ6mNRGz/Q== dependencies: "@types/node" "*" </ins> "@types/yauzl@^2.9.1": version "2.9.1" resolved "https://registry.yarnpkg.com/@types/yauzl/-/yauzl-2.9.1.tgz#d10f69f9f522eef3cf98e30afb684a1e1ec923af"

buffer-crc32 "~0.2.3" fd-slicer "~1.0.1" <ins> yauzl@^3.0.0: version "3.1.1" resolved "https://registry.yarnpkg.com/yauzl/-/yauzl-3.1.1.tgz#d85503cc34933c0bcb3646ee2b97afedbebe32e7" integrity sha512-MPxA7oN5cvGV0wzfkeHKF2/+Q4TkMpHSWGRy/96I4Cozljmx0ph91+Muxh6HegEtDC4GftJ8qYDE51vghFiEYA== dependencies: buffer-crc32 "~0.2.3" pend "~1.2.0" </ins> yazl@^2.2.1, yazl@^2.4.3: version "2.4.3" resolved "https://registry.yarnpkg.com/yazl/-/yazl-2.4.3.tgz#ec26e5cc87d5601b9df8432dbdd3cd2e5173a071"