default npm run to silent

[Raynos]

When we use npm run custom-script, if the custom script exits 1 it currently outputs

npm ERR! dispatch@2.16.0 foo: `exit 1;`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the dispatch@2.16.0 foo script.
npm ERR! This is most likely a problem with the dispatch package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     exit 1;
npm ERR! You can get their info via:
npm ERR!     npm owner ls dispatch
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-24-generic
npm ERR! command "node" "/home/raynos/projects/nvm/v0.10.26/bin/npm" "run" "foo"
npm ERR! cwd /home/raynos/uber/dispatch
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.12
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/raynos/uber/dispatch/npm-debug.log
npm ERR! not ok code 0

This seems like a lot of noise for something that is not part of npm.

When I write a npm run some-script script I am expected to write useful things to stderr when I exit 1. The text generated by npm does actually not help.

We might want to whitelist some certain run scripts like npm run preinstall etc so that it does output this.

However for something truly custom like npm run changelog-patch or npm run shrinkwrap, run targets not used by npm at all, it might make sense to default to silent: true

Suggestion

in lib/run-script.js if the run command is not in a whitelist of [postinstall, preinstall, etc, ...] then do an npm.config.set('silent', true)

[ljharb]

In addition, it would be nice if npm run custom-script did not generate an npm-debug.log by default, since it's not something in npm that needs debugging.

[max-mapper]

it would also be nice if I could set a config to tell npm to never ever write a npm-debug.log ever

[jkrems]

It would also be nice if the spinner is off by default for npm run. Trying to run testem (or something else that does fancy terminal rendering) leads to ugly artifacts.

[faiq]

@Raynos npm is already too noisy, what do you think should be the default whitelist? I'm thinking anything npm runs should log otherwise it should shut up.

EDIT: https://docs.npmjs.com/misc/scripts this gives that list.

[faiq]

also how can you configure this if you do want output from npm?

[faiq]

Sorry for the comment spam, but the more I think about this the more I don't like it. We already have an option --loglevel=silent to make npm quiet. so +0 for this. I would be interested in seeing someone make a config that takes makes npm-debug.log disappear, but maybe that deserves a different issue.

[Raynos]

@faiq You can even do -s for silent.

It's more about default user experience.

[faiq]

@Raynos the new --if-present flag will not create a npm-debug, so I would recommend putting that in your .npmrc for that kind of behavior

[othiym23]

@faiq that only applies if the run-script doesn't exist in package.json, not if the run-script exits with a nonzero exit code.

[faiq]

so i guess the question still remains: if something breaks, and its not npms fault, should you get a debug log

[othiym23]

Here's my take: if a user script errors, the npm process should at the very least exit with a nonzero exit code. In addition, many times there will be useful information about the environment passed to a run-script that crashed, so npm-debug.log is useful. There are definitely situations in which it doesn't make sense to have a logfile on failure (unattended servers run by automatic process management, for instance), but as with most postmortem debugging tools, you often don't know you need the logs until after the fact, so the default should remain to dump a log. Where that goes is, as you know, an open question.

[ngryman]

@Raynos I agree with your initial request, this is too much noise imho.

We should be able to specify that we want another log level for custom scripts than built-in npm command.
For now, we can enforce a 0 exit code by appending || true to all of our commands. This feels clunky...

Another thing, npm test and npm run test behave differently. The former is silent, the latter is verbose. Is this intended?

[mnquintana]

npm run <custom command> is just too noisy right now (especially if it happens to error out). I'd much rather see this default to silent and add a --verbose flag for those who want the full output.

[adametry]

This spoils the use of custom NPM run-scripts for build & deployment abstraction. The run scripts have long exited with the appropriate exit code, but this involves write permissions for the machine/user. The stderr gets messy when EACCESS errors (for npm-debug.log) are thrown in.

[TYRONEMICHAEL]

Is there anyway around this for the time being?

[TYRONEMICHAEL]

Sorry see you can actually remove the noise by appending the --silent flag.

[samueleaton]

my workaround for not writing that pesky npm-debug.log by default was just creating an alias (in .bashprofile or .bashrc) to give npm the ol' silent treatment:

alias npm="npm -s"

Now, if you DO want a command to be print output, it works fine to do npm run <script> --verbose

I guess its not really a workaround... its what aliases are for. See @ivan-kleshnin comment below.

[ivan-kleshnin]

@samueleaton, no, it's not what aliases are for.

Some utils will expect from "npm" to gave this log tail and will break because you substituted it.

For example I was beaten by the very similar stuff nvm-sh/nvm#493

[samueleaton]

@ivan-kleshnin Thanks, I edited my comment. Dang, I want default silence when I'm linting... The fat npm error output takes up my whole terminal and I have to scroll up to see the linter output.

At least there should be an option to have a single line error output from npm. I'm with @mnquintana that we should opt into the verbosity (its a whole paragraph of errors!).

[ivan-kleshnin]

@samueleaton, everyone I asked is for silent default. That text tail is extremely annoying.
All my npm scripts are contaminated by -s flags now.

[ngryman]

Hey guys, I've opened a similar issue, trying to propose "alternatives": #8821.
Would you mind giving some feedback on those possible enhancements?

Thanks!

[adamreisnz]

This problem is amplified if you have a script setup where one npm script calls another via npm run. I end up with something that looks like this after a simple test suite fails:

npm ERR! dispatch@2.16.0 foo: `exit 1;`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the dispatch@2.16.0 foo script.
npm ERR! This is most likely a problem with the dispatch package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     exit 1;
npm ERR! You can get their info via:
npm ERR!     npm owner ls dispatch
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-24-generic
npm ERR! command "node" "/home/raynos/projects/nvm/v0.10.26/bin/npm" "run" "foo"
npm ERR! cwd /home/raynos/uber/dispatch
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.12
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/raynos/uber/dispatch/npm-debug.log
npm ERR! not ok code 0
npm ERR! dispatch@2.16.0 foo: `exit 1;`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the dispatch@2.16.0 foo script.
npm ERR! This is most likely a problem with the dispatch package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     exit 1;
npm ERR! You can get their info via:
npm ERR!     npm owner ls dispatch
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-24-generic
npm ERR! command "node" "/home/raynos/projects/nvm/v0.10.26/bin/npm" "run" "foo"
npm ERR! cwd /home/raynos/uber/dispatch
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.12
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/raynos/uber/dispatch/npm-debug.log
npm ERR! not ok code 0
npm ERR! dispatch@2.16.0 foo: `exit 1;`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the dispatch@2.16.0 foo script.
npm ERR! This is most likely a problem with the dispatch package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     exit 1;
npm ERR! You can get their info via:
npm ERR!     npm owner ls dispatch
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.13.0-24-generic
npm ERR! command "node" "/home/raynos/projects/nvm/v0.10.26/bin/npm" "run" "foo"
npm ERR! cwd /home/raynos/uber/dispatch
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.12
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/raynos/uber/dispatch/npm-debug.log
npm ERR! not ok code 0

In other words, 3 nested error warnings. And putting --silent after every npm run command seems like a bit much. So +1 for a way to turn it off by default, or at least make this exit information less verbose by default.

Since npm is used more and more as a build tool, and we are supposed to run tests and linters with it, then the following message is not really appropriate when tests fail or linters encounter an error:

npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the BookingPro package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run lint

[ELLIOTTCABLE]

Here's what I'm using right now, for reference:

nrs() { script="$1"; shift; npm --silent run-script "$script" -- "$@" ;}
# nrs 'hi!'
# nrs test
# nrs test --grep 'hi'

[nevir]

This would be wonderful

Alternatively, if we were able to target specific commands via a npmrc, that would probably satisfy, too.

Something like:

.npmrc:

[run]
silent=true

?

[ngryman]

I've set up a poll here to gather proposals: https://t.co/wr7gjnsR1b.
If you can spread the word :)

[nebulou5]

I can't get the --silent flag to work at all when running npm (version 3.7.2) scripts from my package.json. The script runs fine, but when any tests fail, npm exits the process.

My scripts are setup as follows...

...
"test": "NODE_ENV=test lab ./build --silent --pattern spec",
"test:watch": "npm run --silent test && chokidar --silent './build/**/*.js' -c 'npm run --silent test'"

I've tried just about every combination of adding the --silent (-s) flag, but I still get this nasty output when running lab through either of the above npm scripts:

npm ERR! Darwin 15.3.0
npm ERR! argv "/usr/local/Cellar/node/5.6.0/bin/node" "/usr/local/bin/npm" "run" "test:orig"
npm ERR! node v5.6.0
npm ERR! npm v3.7.2
npm ERR! code ELIFECYCLE
npm ERR! cl-api@0.1.0 test:orig: NODE_ENV=test lab ./build -s --pattern spec
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the cl-api@0.1.0 test:orig script 'NODE_ENV=test lab ./build -s --pattern spec'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the cl-api package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! NODE_ENV=test lab ./build -s --pattern spec
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs cl-api
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls cl-api
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! ./npm-debug.log

When I run lab directly, I do not get the same logging naturally.

Workaround I've managed to work around this issue by revising my test script to contain || true as mentioned by @ngryman above. My revised test scripts look like this:

...
"test": "NODE_ENV=test lab ./build -P spec || true,
"test:watch": "npm run test && chokidar './build/**/*.js' --silent -c 'npm run test'"
...

I guess maybe lab is just too extreme with their exit codes.

[hazeledmands]

While we're thinking about the real solution, I wrote up a teeny utility called nsrun that does exactly what npm run-script does without all the logging. Hope this is helpful to some!

Install:
  npm install -g nsrun

Run a script defined in package.json:
  nsrun <script-name> <arguments-for-your-script>

[alisianoi]

I am working on an npm package commitplease which makes sure that a git commit message follows some style. When the commit message is bad, the script writes about it to stderr and exits with a non-zero code. The script itself is triggered by another npm package called husky. In a nutshell:

1. git commit triggers .git/hooks/commit-msg bash script by husky
2. this bash script runs the line npm run commitmsg (no silent flag)
3. there is a setting in package.json "commitmsg": "commitplease"
4. commitplease exits with non-zero (in order to abort the commit)
5. npm adds a lot of noise that shadows the useful info on stderr

I have read the suggestions in this thread:

1. "Use the --silent/-s flag":
   1. Husky does not use it because it helps if/when something actually goes wrong silent npm run typicode/husky#26
   2. Injecting that flag from the package.json like "commitmsg": "-s commitplease" does not work
      Complete list of injecting attempts here: don't output npm default error message typicode/husky#47
2. "Append || true to trick the exit code" does not work for me because I want to abort the git commit by a non-zero exit code.
3. "Use a global config" is not an option, I would like npm to be silent when running a particular script.
4. "Use an alias for npm" or nsrun are not an option either: first requires manual config from the user and second requires a change to husky.

How could I silence npm when a particular npm run <script> is called?

[othiym23]

I'm going to close this in favor of #8821, which has a more tightly scoped definition of the problem (as well as a proposal for what looks like a sensible solution). Thanks to all for your time and discussion!

[tobia]

@ivan-kleshnin I know this thread is quite old, but I would like to rectify a statement:

alias npm="npm -s"

it's not what aliases are for. Some utils will expect from "npm" to gave this log tail and will break because you substituted it.

This is wrong, @samueleaton was indeed right to suggest using an alias. Setting preferred flags, only when the commands are used interactively in a terminal, is exactly what Bash aliases are for. If a script breaks because you have an alias in your .bashrc, then there is something very wrong with that script or with your setup.

Here's an example of how scripts completely ignore aliases:

$ grep NOPE .bashrc
alias echo='echo NOPE'

$ cat script.sh
#!/bin/bash
echo "In the script"

$ echo "On the terminal"
NOPE On the terminal

$ ./script.sh 
In the script