Skip to content
This repository has been archived by the owner. It is now read-only.

default npm run to silent #5452

Closed
Raynos opened this Issue Jun 10, 2014 · 30 comments

Comments

Projects
None yet
@Raynos
Copy link
Contributor

Raynos commented Jun 10, 2014

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

This comment has been minimized.

Copy link
Contributor

ljharb commented Jun 10, 2014

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.

@maxogden

This comment has been minimized.

Copy link

maxogden commented Jun 10, 2014

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

@jkrems

This comment has been minimized.

Copy link

jkrems commented Aug 16, 2014

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

This comment has been minimized.

Copy link
Contributor

faiq commented Jan 12, 2015

@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

This comment has been minimized.

Copy link
Contributor

faiq commented Jan 12, 2015

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

@faiq

This comment has been minimized.

Copy link
Contributor

faiq commented Jan 13, 2015

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

This comment has been minimized.

Copy link
Contributor Author

Raynos commented Jan 13, 2015

@faiq You can even do -s for silent.

It's more about default user experience.

@faiq

This comment has been minimized.

Copy link
Contributor

faiq commented Feb 27, 2015

@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

This comment has been minimized.

Copy link
Contributor

othiym23 commented Feb 27, 2015

@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

This comment has been minimized.

Copy link
Contributor

faiq commented Feb 28, 2015

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

@othiym23

This comment has been minimized.

Copy link
Contributor

othiym23 commented Feb 28, 2015

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

This comment has been minimized.

Copy link

ngryman commented May 28, 2015

@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

This comment has been minimized.

Copy link

mnquintana commented Jul 8, 2015

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 comment has been minimized.

Copy link

adametry commented Jul 31, 2015

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

This comment has been minimized.

Copy link

TYRONEMICHAEL commented Sep 30, 2015

Is there anyway around this for the time being?

@TYRONEMICHAEL

This comment has been minimized.

Copy link

TYRONEMICHAEL commented Sep 30, 2015

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

@samueleaton

This comment has been minimized.

Copy link

samueleaton commented Oct 7, 2015

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

This comment has been minimized.

Copy link

ivan-kleshnin commented Oct 8, 2015

@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 creationix/nvm#493

@samueleaton

This comment has been minimized.

Copy link

samueleaton commented Oct 8, 2015

@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

This comment has been minimized.

Copy link

ivan-kleshnin commented Oct 12, 2015

@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

This comment has been minimized.

Copy link

ngryman commented Oct 13, 2015

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 comment has been minimized.

Copy link

adamreisnz commented Feb 16, 2016

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

This comment has been minimized.

Copy link

ELLIOTTCABLE commented Feb 20, 2016

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 comment has been minimized.

Copy link

nevir commented Mar 1, 2016

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

This comment has been minimized.

Copy link

ngryman commented Mar 1, 2016

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

@FuzzySockets

This comment has been minimized.

Copy link

FuzzySockets commented Apr 26, 2016

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.

@demands

This comment has been minimized.

Copy link

demands commented Jun 4, 2016

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

This comment has been minimized.

Copy link

alisianoi commented Jun 7, 2016

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 typicode/husky#26
    2. Injecting that flag from the package.json like "commitmsg": "-s commitplease" does not work
      Complete list of injecting attempts here: 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

This comment has been minimized.

Copy link
Contributor

othiym23 commented Jul 19, 2016

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!

@othiym23 othiym23 closed this Jul 19, 2016

@tobia

This comment has been minimized.

Copy link

tobia commented Apr 19, 2017

@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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.