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
Closed

default npm run to silent #5452

Raynos opened this issue Jun 10, 2014 · 30 comments

Comments

@Raynos
Copy link
Contributor

@Raynos 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
Copy link
Contributor

@ljharb 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
Copy link

@maxogden 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
Copy link

@jkrems 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
Copy link
Contributor

@faiq 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
Copy link
Contributor

@faiq faiq commented Jan 12, 2015

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

@faiq
Copy link
Contributor

@faiq 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
Copy link
Contributor Author

@Raynos Raynos commented Jan 13, 2015

@faiq You can even do -s for silent.

It's more about default user experience.

@faiq
Copy link
Contributor

@faiq 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
Copy link
Contributor

@othiym23 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
Copy link
Contributor

@faiq 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
Copy link
Contributor

@othiym23 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
Copy link

@ngryman 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
Copy link

@mnquintana 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
Copy link

@adametry 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
Copy link

@TYRONEMICHAEL TYRONEMICHAEL commented Sep 30, 2015

Is there anyway around this for the time being?

@TYRONEMICHAEL
Copy link

@TYRONEMICHAEL TYRONEMICHAEL commented Sep 30, 2015

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

@samueleaton
Copy link

@samueleaton 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
Copy link

@ivan-kleshnin 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 nvm-sh/nvm#493

@samueleaton
Copy link

@samueleaton 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
Copy link

@ivan-kleshnin 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
Copy link

@ngryman 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
Copy link

@adamreisnz 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
Copy link

@ELLIOTTCABLE 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
Copy link

@nevir 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
Copy link

@ngryman 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
Copy link

@FuzzySockets 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.

@maxedmands
Copy link

@maxedmands maxedmands 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
Copy link

@alisianoi 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
Copy link
Contributor

@othiym23 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
Copy link

@tobia 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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet