WebStorm - How to find source of a problem inside a npm package? (node:36378) [DEP0005] DeprecationWarning
up vote
2
down vote
favorite
I started getting this error in the last 6 months, probably because of a update to node.js.
(node:36378) [DEP0005] DeprecationWarning: Buffer() is deprecated due
to security and usability issues. Please use the Buffer.alloc(),
Buffer.allocUnsafe(), or Buffer.from() methods instead.
I've pinpointed the specific package that is causing this warning: https://github.com/irhc/js-logging
It's no longer maintained so I have to dig down and find the source of this problem. However my IDE (WebStorm) is not showing any lines of code. I also searched the source code and couldn't find Buffer() used anywhere. How can I find the source of this problem?
Btw I'm also using fs in the same file, which actually has Buffer() inside, but commenting out the dependency and related functions didn't get rid of the warning.
Edit: Thanks to the suggestions by @ix3 I lowered the scope of the problem
- This doesn't happen while running in node server
- This doesn't happen while running mocha test from terminal https://prnt.sc/lh012c
- This does happen when running mocha tests from
Webstorm: https://prnt.sc/lh01ac
So the problem is in the interaction of Webstorm + Mocha + Node + js-logging. Each of them work perfectly alone, but I get this error when they are together.
javascript node.js logging buffer webstorm
|
show 3 more comments
up vote
2
down vote
favorite
I started getting this error in the last 6 months, probably because of a update to node.js.
(node:36378) [DEP0005] DeprecationWarning: Buffer() is deprecated due
to security and usability issues. Please use the Buffer.alloc(),
Buffer.allocUnsafe(), or Buffer.from() methods instead.
I've pinpointed the specific package that is causing this warning: https://github.com/irhc/js-logging
It's no longer maintained so I have to dig down and find the source of this problem. However my IDE (WebStorm) is not showing any lines of code. I also searched the source code and couldn't find Buffer() used anywhere. How can I find the source of this problem?
Btw I'm also using fs in the same file, which actually has Buffer() inside, but commenting out the dependency and related functions didn't get rid of the warning.
Edit: Thanks to the suggestions by @ix3 I lowered the scope of the problem
- This doesn't happen while running in node server
- This doesn't happen while running mocha test from terminal https://prnt.sc/lh012c
- This does happen when running mocha tests from
Webstorm: https://prnt.sc/lh01ac
So the problem is in the interaction of Webstorm + Mocha + Node + js-logging. Each of them work perfectly alone, but I get this error when they are together.
javascript node.js logging buffer webstorm
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by runningmkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');"(it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0
– iX3
Nov 8 at 16:08
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06
|
show 3 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I started getting this error in the last 6 months, probably because of a update to node.js.
(node:36378) [DEP0005] DeprecationWarning: Buffer() is deprecated due
to security and usability issues. Please use the Buffer.alloc(),
Buffer.allocUnsafe(), or Buffer.from() methods instead.
I've pinpointed the specific package that is causing this warning: https://github.com/irhc/js-logging
It's no longer maintained so I have to dig down and find the source of this problem. However my IDE (WebStorm) is not showing any lines of code. I also searched the source code and couldn't find Buffer() used anywhere. How can I find the source of this problem?
Btw I'm also using fs in the same file, which actually has Buffer() inside, but commenting out the dependency and related functions didn't get rid of the warning.
Edit: Thanks to the suggestions by @ix3 I lowered the scope of the problem
- This doesn't happen while running in node server
- This doesn't happen while running mocha test from terminal https://prnt.sc/lh012c
- This does happen when running mocha tests from
Webstorm: https://prnt.sc/lh01ac
So the problem is in the interaction of Webstorm + Mocha + Node + js-logging. Each of them work perfectly alone, but I get this error when they are together.
javascript node.js logging buffer webstorm
I started getting this error in the last 6 months, probably because of a update to node.js.
(node:36378) [DEP0005] DeprecationWarning: Buffer() is deprecated due
to security and usability issues. Please use the Buffer.alloc(),
Buffer.allocUnsafe(), or Buffer.from() methods instead.
I've pinpointed the specific package that is causing this warning: https://github.com/irhc/js-logging
It's no longer maintained so I have to dig down and find the source of this problem. However my IDE (WebStorm) is not showing any lines of code. I also searched the source code and couldn't find Buffer() used anywhere. How can I find the source of this problem?
Btw I'm also using fs in the same file, which actually has Buffer() inside, but commenting out the dependency and related functions didn't get rid of the warning.
Edit: Thanks to the suggestions by @ix3 I lowered the scope of the problem
- This doesn't happen while running in node server
- This doesn't happen while running mocha test from terminal https://prnt.sc/lh012c
- This does happen when running mocha tests from
Webstorm: https://prnt.sc/lh01ac
So the problem is in the interaction of Webstorm + Mocha + Node + js-logging. Each of them work perfectly alone, but I get this error when they are together.
javascript node.js logging buffer webstorm
javascript node.js logging buffer webstorm
edited Nov 11 at 15:51
asked Nov 8 at 3:25
Esqarrouth
24k11117129
24k11117129
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by runningmkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');"(it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0
– iX3
Nov 8 at 16:08
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06
|
show 3 more comments
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by runningmkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');"(it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0
– iX3
Nov 8 at 16:08
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by running
mkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');" (it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0– iX3
Nov 8 at 16:08
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by running
mkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');" (it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0– iX3
Nov 8 at 16:08
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
The fact that js-logging is no longer maintained makes it a sensible first place to look. However, if it is not calling new Buffer (and neither are any of its dependencies) then something else must be triggering that warning message. How did you "pinpoint" the problem to that package?
You might want to try running your program with a debugger (e.g. the one built into Chrome) attached. You can do this by following the instructions that Paul Irish explains here. Also note that Chrome 70 now offers ndb.
You can also try "grepping" your entire source tree (including node_modules) for "new Buffer". There are multiple ways to do this, and they vary by operating system. For example, on a POSIX system like Linux you can usually do something like grep -drecurse "new Buffer" . from the root folder of your project to search for all occurrences of that string in all files within that tree.
Finally, it bears repeating that the message you listed is not an error but only a warning. Consequently, it is not causing any different behavior. In other words, fixing it will only make the message go away; it will not significantly change the behavior of your program. Of course, you should still strive to address it as the warning is telling you that in a future version of node the code you have right now will stop working.
Edit: Looking at the audio-less videos you shared, it looks like you are doing all kinds of things that your question didn't mention, e.g.
- You are writing in TypeScript (What happens when you use plain JavaScript?)
- You are only running the tests from within the IDE (What happens when you run them from the command line?)
It's quite possible that you are using an old version of ts-node which used the Buffer constructor until about May 2018.
Aside: To track when dependencies change (especially dependencies of dependencies of ....) I strongly recommend using yarn or at least package-lock.json as otherwise it is completely possible that your app will build and work one day and not the next due to changes upstream.
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The fact that js-logging is no longer maintained makes it a sensible first place to look. However, if it is not calling new Buffer (and neither are any of its dependencies) then something else must be triggering that warning message. How did you "pinpoint" the problem to that package?
You might want to try running your program with a debugger (e.g. the one built into Chrome) attached. You can do this by following the instructions that Paul Irish explains here. Also note that Chrome 70 now offers ndb.
You can also try "grepping" your entire source tree (including node_modules) for "new Buffer". There are multiple ways to do this, and they vary by operating system. For example, on a POSIX system like Linux you can usually do something like grep -drecurse "new Buffer" . from the root folder of your project to search for all occurrences of that string in all files within that tree.
Finally, it bears repeating that the message you listed is not an error but only a warning. Consequently, it is not causing any different behavior. In other words, fixing it will only make the message go away; it will not significantly change the behavior of your program. Of course, you should still strive to address it as the warning is telling you that in a future version of node the code you have right now will stop working.
Edit: Looking at the audio-less videos you shared, it looks like you are doing all kinds of things that your question didn't mention, e.g.
- You are writing in TypeScript (What happens when you use plain JavaScript?)
- You are only running the tests from within the IDE (What happens when you run them from the command line?)
It's quite possible that you are using an old version of ts-node which used the Buffer constructor until about May 2018.
Aside: To track when dependencies change (especially dependencies of dependencies of ....) I strongly recommend using yarn or at least package-lock.json as otherwise it is completely possible that your app will build and work one day and not the next due to changes upstream.
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
add a comment |
up vote
1
down vote
The fact that js-logging is no longer maintained makes it a sensible first place to look. However, if it is not calling new Buffer (and neither are any of its dependencies) then something else must be triggering that warning message. How did you "pinpoint" the problem to that package?
You might want to try running your program with a debugger (e.g. the one built into Chrome) attached. You can do this by following the instructions that Paul Irish explains here. Also note that Chrome 70 now offers ndb.
You can also try "grepping" your entire source tree (including node_modules) for "new Buffer". There are multiple ways to do this, and they vary by operating system. For example, on a POSIX system like Linux you can usually do something like grep -drecurse "new Buffer" . from the root folder of your project to search for all occurrences of that string in all files within that tree.
Finally, it bears repeating that the message you listed is not an error but only a warning. Consequently, it is not causing any different behavior. In other words, fixing it will only make the message go away; it will not significantly change the behavior of your program. Of course, you should still strive to address it as the warning is telling you that in a future version of node the code you have right now will stop working.
Edit: Looking at the audio-less videos you shared, it looks like you are doing all kinds of things that your question didn't mention, e.g.
- You are writing in TypeScript (What happens when you use plain JavaScript?)
- You are only running the tests from within the IDE (What happens when you run them from the command line?)
It's quite possible that you are using an old version of ts-node which used the Buffer constructor until about May 2018.
Aside: To track when dependencies change (especially dependencies of dependencies of ....) I strongly recommend using yarn or at least package-lock.json as otherwise it is completely possible that your app will build and work one day and not the next due to changes upstream.
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
add a comment |
up vote
1
down vote
up vote
1
down vote
The fact that js-logging is no longer maintained makes it a sensible first place to look. However, if it is not calling new Buffer (and neither are any of its dependencies) then something else must be triggering that warning message. How did you "pinpoint" the problem to that package?
You might want to try running your program with a debugger (e.g. the one built into Chrome) attached. You can do this by following the instructions that Paul Irish explains here. Also note that Chrome 70 now offers ndb.
You can also try "grepping" your entire source tree (including node_modules) for "new Buffer". There are multiple ways to do this, and they vary by operating system. For example, on a POSIX system like Linux you can usually do something like grep -drecurse "new Buffer" . from the root folder of your project to search for all occurrences of that string in all files within that tree.
Finally, it bears repeating that the message you listed is not an error but only a warning. Consequently, it is not causing any different behavior. In other words, fixing it will only make the message go away; it will not significantly change the behavior of your program. Of course, you should still strive to address it as the warning is telling you that in a future version of node the code you have right now will stop working.
Edit: Looking at the audio-less videos you shared, it looks like you are doing all kinds of things that your question didn't mention, e.g.
- You are writing in TypeScript (What happens when you use plain JavaScript?)
- You are only running the tests from within the IDE (What happens when you run them from the command line?)
It's quite possible that you are using an old version of ts-node which used the Buffer constructor until about May 2018.
Aside: To track when dependencies change (especially dependencies of dependencies of ....) I strongly recommend using yarn or at least package-lock.json as otherwise it is completely possible that your app will build and work one day and not the next due to changes upstream.
The fact that js-logging is no longer maintained makes it a sensible first place to look. However, if it is not calling new Buffer (and neither are any of its dependencies) then something else must be triggering that warning message. How did you "pinpoint" the problem to that package?
You might want to try running your program with a debugger (e.g. the one built into Chrome) attached. You can do this by following the instructions that Paul Irish explains here. Also note that Chrome 70 now offers ndb.
You can also try "grepping" your entire source tree (including node_modules) for "new Buffer". There are multiple ways to do this, and they vary by operating system. For example, on a POSIX system like Linux you can usually do something like grep -drecurse "new Buffer" . from the root folder of your project to search for all occurrences of that string in all files within that tree.
Finally, it bears repeating that the message you listed is not an error but only a warning. Consequently, it is not causing any different behavior. In other words, fixing it will only make the message go away; it will not significantly change the behavior of your program. Of course, you should still strive to address it as the warning is telling you that in a future version of node the code you have right now will stop working.
Edit: Looking at the audio-less videos you shared, it looks like you are doing all kinds of things that your question didn't mention, e.g.
- You are writing in TypeScript (What happens when you use plain JavaScript?)
- You are only running the tests from within the IDE (What happens when you run them from the command line?)
It's quite possible that you are using an old version of ts-node which used the Buffer constructor until about May 2018.
Aside: To track when dependencies change (especially dependencies of dependencies of ....) I strongly recommend using yarn or at least package-lock.json as otherwise it is completely possible that your app will build and work one day and not the next due to changes upstream.
edited Nov 8 at 21:14
answered Nov 8 at 3:52
iX3
4,77632753
4,77632753
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
add a comment |
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
js-logging doesn't seem to have dependencies anyways
– Esqarrouth
Nov 8 at 18:53
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53201124%2fwebstorm-how-to-find-source-of-a-problem-inside-a-npm-package-node36378-d%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
In order for others to be able to help you better, please post more information about your program. Is it a NodeJS program or does it run in a web browser? When do you see the error message you mentioned? What version of NodeJS are you using? Can you share a simple example that reproduces the problem in a github repository or gist? etc.
– iX3
Nov 8 at 3:37
The problematic file is the backend side of a web application. Specifically it is a custom wrapper for the logging library. The purpose of the wrapper is to write all logs into into files .log.
– Esqarrouth
Nov 8 at 15:56
That's a start but unfortunately still isn't enough information to help you further. For example, I can't reproduce the problem simply by running
mkdir tmp; cd tmp; npm init -y; npm install --save js-logging; node -e "require('js-logging').console().debug('Hello, world');"(it outputs "2018-11-08T10:07:23-0600 <debug> [eval]:1 Hello, world" just fine). Ran on Debian Linux 9.5 with NodeJS 10.13.0– iX3
Nov 8 at 16:08
Just realized I've jumped to a conclusion. The problem doesn't seem to be with node.js or that file. The problem is that file + Webstorm + Chai testing. This warning doesn't show in my terminal when I run the app, but it does show when I'm running tests. But only when I use this file. I'll take a video of it. Thanks for trying to help
– Esqarrouth
Nov 8 at 18:54
I took 2 videos, showing the problem: dropbox.com/sh/4s2iyeotno7zmgr/AACuojCj1_9VYunanUFz0tlfa?dl=0 You can see how annoying it could be when I'm testing hundreds of stuff and in between my results, I'm seeing a warning.
– Esqarrouth
Nov 8 at 19:06