You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] When run script loglevel is ignored unless set to "silent" #3354
The only way to silence the log message is by setting --loglevel silent
The problem is that setting loglevel in .npmrc silences also valid messages from npm. I had to spent too much time to debug why npm was not installing my application. Removing .npmrc revealed a version problem in my packages.
BTW this issue is a re-submission for npm@7 of #2468 for npm@6
Expected Behavior
If it is not an error, nothing should be shown by npm, only the script messages should appear.
Steps To Reproduce
Create a directory with a project in it
Edit package.json and add script "start": "node -e console.log('Hello')"
Run npm start. It shows the log
Run npm start --loglevel error. It show the log message, but it should not, it is not an error
Run npm start --loglevel silent. No log message.
Environment
OS: Windows 10 64bits
Node: 16.2.0
npm: 7.15.1
Reacted by Nicolas Peugnet, Ilmurat Kerimov and Cameron Tacklind
hi @crystalfp thanks for taking the time to reporting this, there are a few other loglevel/output issues that this makes me think of that we were currently tackling:
From my point of view it seems to me that tweaking npm run to only print errors (maybe only print the stderr stream from the child process?) is a reasonable thing to do.
@lukekarrys I'd love to hear your thoughts on it, I know you've been handling the overall output clean up so this one is a very good one to keep in mind.
Well, I got into the habit of using always the -s option. So in case of strange behaviors, I simply rerun npm without it. Having a functioning loglevel option (or something similar) that I can put in the .npmrc file and forget it is sure much simpler.
In bcc781a, this output was moved from stdout to stderr when in --json mode.
I think this should probably be what happens all the time, but that would be a breaking change. I documented the new behavior with a comment in the code indicating this should be changed in the future. I think these should probably be log messages with a level of info (but maybe still rendered with a > prefix) so they can be hidden with the standard loglevel filters.
I'm going to close this since we wont be tracking it as a bug. Instead it's on the v11 roadmap issue since changing it would be a breaking change npm/statusboard#488
Activity
ruyadorno commentedon Mar 3, 2022
hi @crystalfp thanks for taking the time to reporting this, there are a few other loglevel/output issues that this makes me think of that we were currently tackling:
From my point of view it seems to me that tweaking
npm runto only print errors (maybe only print the stderr stream from the child process?) is a reasonable thing to do.@lukekarrys I'd love to hear your thoughts on it, I know you've been handling the overall output clean up so this one is a very good one to keep in mind.
crystalfp commentedon Mar 4, 2022
Well, I got into the habit of using always the
-soption. So in case of strange behaviors, I simply rerun npm without it. Having a functioning loglevel option (or something similar) that I can put in the .npmrc file and forget it is sure much simpler.lukekarrys commentedon May 13, 2024
In bcc781a, this output was moved from stdout to stderr when in
--jsonmode.I think this should probably be what happens all the time, but that would be a breaking change. I documented the new behavior with a comment in the code indicating this should be changed in the future. I think these should probably be log messages with a level of
info(but maybe still rendered with a>prefix) so they can be hidden with the standard loglevel filters.cli/lib/utils/display.js
Lines 321 to 326 in b54cdb8
lukekarrys commentedon May 14, 2024
I'm going to close this since we wont be tracking it as a bug. Instead it's on the v11 roadmap issue since changing it would be a breaking change npm/statusboard#488
wraithgar commentedon Apr 6, 2026
This did not make it into npm 11 but it will be in npm 12. PR is up, it's on the npm 12 roadmap