npm install should be quiet #2040

Closed
defunctzombie opened this Issue Jan 15, 2012 · 50 comments
@defunctzombie

There should be a way to silence output from npm install for successful installations (--quiet comes to mind). Even currently when there is nothing to install it outputs a blank line for some reason. This is quite annoying if using npm from a crontab or other environment where output usually means something needs to be debugged.

@isaacs
npm member

The arg is --silent. Or npm config set loglevel warn if you want to only print warnings and errors. Or you can pipe it to /dev/null.

All configuration options are documented in npm help config

@isaacs isaacs closed this Jan 15, 2012
@defunctzombie

Thanks for the info. Sorry about the failure to rtfm. I would recommend adding --quiet as an alias as it more conventional iirc.

@isaacs
npm member

Good idea :)

@defunctzombie

Note: Even with --silent 'npm install' seems to omit an empty line

@defunctzombie

I just ran npm 1.1.1 using "npm install --silent" and had debug output for the packages it installed. Regression?

@isaacs
npm member

@shtylman We're on 1.1.4 now. Please update.

@defunctzombie

I did, same issues. --quiet is not actually quiet

@isaacs
npm member

--quiet is like --loglevel=warn. --silent is --loglevel=silent (which suppresses even warnings and errors.) The default loglevel setting is --loglevel=http, which shows http request and responses, warnings, and errors.

@defunctzombie

I ran with --silent as well and it produced the same output. I am testing by blowing away the node_modules folder and just running "npm install" with the --quiet or --silent flag respectively. Neither seems to work as I expect.

@isaacs
npm member

What packages are you installing?

I don't see any debug output on stderr with --silent, but it does write the results to stdout.

@defunctzombie

All sorts, mongoose, bcrypt, stylus, express, nodeunit

@isaacs
npm member

What output are you seeing? Log messages, or just the tree output at the very end telling you (on stdout) what was installed?

@defunctzombie

the build output (for bcrypt) and then then the tree output at the end telling me what was installed.

@isaacs
npm member

npm passes the [0,1,2] file descriptors to child processes that build things. It's up to bcrypt at that point. The output at the end telling you what was installed is not covered by --silent. That flag only affects debug log output. The stdout output is part fo the contract with the install command.

If you want it truly 100% silent, then direct the output to /dev/null.

npm install &>/dev/null

and that will be 100% silent.

@isaacs
npm member

For comparison: When you curl -s http://some/url, it suppresses all the debug log output, but it still writes the response body to stdout.

@defunctzombie

The curl example isn't quite the same because the point of curl is to fetch the url and output what it got. The point of npm is to install packages :) I understand about the /dev/null was just hoping for a flag that would silence, but ok.

@leecookson

This may be slightly off-topic, but there are a few npm commands that use console.log, which bypasses the npmlog and --loglevel functionality. Once example is npm.view, which has 3 parameters in the signature, but the command-line interface, htrough the npm.commandCache always sends 2 parameters: args and cb. The code handles this gracefully by defaulting silent to false in all cases. Other functions that use a second, un-passable "silent" parameter:
outdated
bin
pack
prefix
root
search
shrinkwrap
version
whoami
In my case, I'm calling npm.view programmatically, and I'm getting the console.log of the package info, though I don't want to display it.

I understand many of these functionalities are inherently output-oriented, and generally should output information, but that should be the reponsibility of the CLI layer. I could refactor some of these "output from API" as a pull-request.

If there's a simpler way to call npm.view and also pass in "true" for the silent parameter, that would be helful. I'd rather not mess with the internals of the npm command cache.

@leecookson

I see I can do this:

npm.commands['view']([packageSpec], true, function (err, info){ });

but I'd consider this "messing with the internals of npm's command cache".

@isaacs
npm member

@leecookson If you are calling npm.commands.view programmatically, why not just pass the 'silent' param yourself? I don't get it.

// be quiet!
npm.commands.view(['some-package', 'some-field'], true, function (er, data) {
  ... 
})

If you're calling it programmatically from the command line, then pipe just stdout to /dev/null or something in that child process.

@isaacs
npm member

Oic, are you saying that install should have the same silent flag?

That I agree with, but it's a lot of tedious work to trace through all the places where it's called as install(where, what, cb) and provide a cleaner internal API for that. If someone wants to do it, I'd accept a patch.

@leecookson

After RTFM, I realized that the "normal" way to use npm commands through the API is
npm.commands.xxxxx
and that
npm.xxxxx
is a special case. All clear now.

@mikermcneil

I believe there is still an issue here, but only for programmatic usage (see #4320 for a proposed solution)

@gretel

no silence with 1.4.26 neither using --silent nor --quiet and evenly not --loglevel warn

@monokrome

I think that it's worth noting that a related issue here is that the default behavior should be --silent. The unix philosophy suggests that "When a program has nothing surprising to say, it should say nothing." I've personally always found it peculiar that NPM does not respect this.

In general, if a tool works and the goal of the program isn't specifically to send something to standard output (EG, ls, ps, cat) then it shouldn't output anything there unless specifically requested by the user. If it breaks, then it should let you know that it broke. This means that npm's default behavior should actually be the behavior of --silent, and --silent is not necessary because it would be the default behavior. It may be necessary if there were a setting to allow users to default to --verbose, though.

This also means that bash (for example) scripts that use NPM won't be screaming a ton of output through my SSH terminal. It shouldn't be the case that npm magically runs faster when you run it in screen, detach, and then reattach when it's finished due to network I/O bottleneck of sending I/O over SSH. Nor should it be an issue that bash scripts need to manually forward NPM's output to /dev/null when it's working properly.

When I run mkdir example, I wouldn't expect a ton of verbosity in regard to everything that happened on the filesystem. I feel like the same rules should be considered by NPM itself.

@kud

+1 @monokrome

I don't know if there's a solution but I hate seeing commands which are started via npm run. I would like a clean interface like if I did:

@echo '> Starting compilation...'
@npm run compile-scripts
@npm run compile-styles

I will only see the title and the result of compilation, not the commands started. It's clearer.

@twjacobsen

If you want it truly 100% silent, then direct the output to /dev/null.

npm install &>/dev/null
and that will be 100% silent.

Just a quick comment here, since I'm also looking for a way to silence npm (update, though).

Using the above method sure does silence NPM.. It even removes the spinning /, which was another thing I had been wishing for for a long time.

Soo, using &>/dev/null silences NPM alright, but at the same time removes any indication of progress. Meh... :(

Still wishing for a --silent or --quiet flag, that just removes any spamming output, except the nice working-indicator.

@mikermcneil

Just a quick comment here, since I'm also looking for a way to silence npm (update, though).

@nesler so we've been using this for installs- could add one for update using this

@mikermcneil

@nesler or you can grab the tarball directly w/o using the childproc approach w/ http://node-machine.org/machinepack-npm/download-package

@mikalai-silivonik

@mikermcneil thanks for sharing!

switched to enpeem just because of a single line

@SimenB

@othiym23 Any thoughts on @monokrome's idea regarding making npm silent by default?

@othiym23

@SimenBIn general, the Unix philosophy is a great way to create simple, composable tools (and is a cornerstone of the philosophy of small modules that npm advocates). npm the tool, though, is not a small tool, and already does many things, and is an end-user tool. Making npm quieter by default would make it easier to use in tooling pipelines, but would make it much more confusing for casual users, which would in turn make it much more time-consuming to support (small usability tweaks have large knock-on impacts on how many new issues get filed against npm). As one of the people primarily responsible for supporting npm, I'm not enthusiastic about doing things that make npm harder to support, and as such @monokrome's change isn't one I'm interested in making.

@SimenB

@othiym23 Thanks for the detailed response. That makes sense!

@monokrome

Telling people what actually breaks when there is an error and not telling them all the stuff that they don't care about doesn't seem like it would make things harder to support.

@othiym23

We get many, many support issues from people who take the absence of output as evidence that the command didn't work, which is why many of npm's formerly silent subcommands have sprouted some (minimal) output over the life of npm@2.

This was referenced Jul 26, 2015
@thomasf

This verbose behaviour is extremley annoying to say the least and in a direct opposite to how most other tools works. I don't see why there can't be an option to just silence that enormous mass of text of installed packages after an install..

Also. people need to learn that they don't have to be notified unless there are problems. Its the only way to make sens of large build outputs.

@thomasf

@othiym23 regardless of what is silent per default it's really strange that there isn't a way to disable the summary tree at the end. I have a CI job that has to run npm a bunch of times and all warnings and stuff are completely hidden among all crap npm is outputting.. If npm is an end user tool, which tool is the one I should use for automation which has full package.json support?

Piping to /dev/null is probably not a particularly good workaround since it might also hide actual problems. I guess I could create a wrapper which holds the entire stderr/stdout from npm and only display it if the exit code is non zero but that adds a special case tool into the build chain which isn't desirable at all.

@Tectract

+1

during npm install today, it popped up about a thousand popup error boxes warning me about missing files. That should NOT EVER EVER EVER EVER EVER EVER EVER EVER happen.

@codename-

+1 what @thomasf said: adding --no-summary flag could be good thing if we don't want to modify a logLevel behaviour.

@adam77

--no-summary would be great (or even better gets omitted in --quiet mode)

@ChrisPearce

+1 for a --no-summary flag.

Having the option to decide whether to output the summary would be very helpful.

@walgitrus

redirecting output to stdout is a non-starter. i want to see error messages.
being verbose by default is fine, provided there is a way to reduce it

i have no interest in spinners, dependency trees, or any of the other crap that npm spits out—even though i specifically run with --loglevel=warn or --silent or --quiet. i even have spin = false in my config but nothing seems to keep that effing progress meter off my screen.

a tool written by tools for tools.

@KenanY
npm member

@walgitrus For npm@3 at least, I do not think the spin is an actual config setting. Are you looking for progress?

@iainhouston

Apologies for nagging away at this again but please, no tree by default.

I have to agree that, as much as I love and appreciate npm, I do find that 913 lines of output (including the tree) to install a relatively simple package.json for watching, compiling and browser syncing my style files is shouting "something is wrong" when nothing is wrong.

I know npm is doing wonderful things for me (reliably installing 2031 directories, 9435 files) but I am perfectly capable of typing tree node_modules/ on those occasions that I actually need to see the tree

@qw3rtman

@iainhouston in the meantime, try --depth 0:

npm list --depth 0
@iainhouston

Thanks @qw3rtman, npm install --depth 0 does cut down the output to a sensible level

@rmilesson

Also +1 on a --no-summary option. Seeing that module-tree after npm install in our CI-logs is absolutely horrible.

@joelanman joelanman referenced this issue in alphagov/govuk_prototype_kit Feb 4, 2016
Closed

Display message at end of npm install indicating it's done #136

@joelanman

neither npm install --silent or --quiet seem to hide the tree - is there no way of achieving this?

We've found in our user research that the tree is complex and confusing. We're trying to add a nice "all done" message using a postinstall script, but it gets output before the tree, and therefore not seen by the user.

@hunterloftis

I would also love to be able to silence npm installs again (this used to work in the Heroku buildpack, but hasn't for a while).

@Pharylon

@hunterloftis and @joelanman, @rmilesson:

Until they fix this, you can pipe the output to dev/null (or out-null if you're using Powershell).

@joelanman

@Pharylon but that would hide any actually useful output, such as errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment