Excessive npm log output in 4.x

[FrederikNJS]

When running NPM in the 4.x version of the docker image, the image runs with
ENV NPM_CONFIG_LOGLEVEL info
Is there any reason why this is not "warn" as is usually the default?

The log output is enough for Travis-CI to complain that the log output is too long.

[Starefossen]

Yes, here is my rationale for changing this in the iojs Docker Image a while back: nodejs/docker-iojs#36

[jackwanders]

We've recently run into this excessive output when we started using node 4.2.x containers. The change looks like it goes back to the initial prep work for node 4.x images done by @chorrell (see e763a10).

Personally, it seems undesirable to override any defaults here. The default loglevel in npm is "warn", and to have it overridden to be "info" is unexpected and requires us to override it again in our own Dockerfiles.

[chorrell]

That's a fair point.

I'm fine with removing the loglevel setting if everyone else is.

Thoughts from @nodejs/docker team?

[Starefossen]

I disagree. npm operates under the assumption that you can always get to the npm log file.

[jackwanders]

Having read the docker-iojs PR that @Starefossen links to above, I would still advocate for user education in the case of a failed package installation over dumping unnecessary information into the CI logs of the overwhelming majority of docker build / docker run jobs in the wild.

[mnylen]

At least document clearly how you can get the default behaviour back. Simple "npm config set loglevel warn" did not work for me, because the NPM_CONFIG_LOGLEVEL set in this image was overriding it. Instead, to get the default log level of "warn" back, you need to add:

ENV NPM_CONFIG_LOGLEVEL warn

to your own Dockerfile.

[retrohacker]

@Starefossen I'm 👍 on warn since npm-debug.log will be lost when the container stops.

We should document possible workarounds for places where this may not be ideal.

For example: npm install --loglevel=warn > /var/log/npm.log 2>&1 || cat /var/log/npm.log && false will only print the log if the install fails.

[HackAttack]

+1 for removing this setting and using npm's default behavior.

[Starefossen]

From long experience with linux, c, and makefiles you want your builds and installs to be as verbose as possible so that you could have a propper log to work with when things fail. Since almost all of the npm stuff is network dependent, and just recently added consistent unpacking, you are not guaranteed that things will fail the same way next time you run (with a more verbose log level).

I believe this is just as true for Docker since often you do not have access to the npm.log, and many containers are run with docker run --rm which deletes the container after it exits regardless of the exit code.

I also do not buy the argument about not being the default setting and hence it should not be in the image. We must be free to optimise the settings for the Docker runtime and the ways Docker is used different form other platforms.

From my investigation this is only really an issue on Travis CI which has a 4MB output limit travis-ci/travis-ci#1382.

---

@HackAttack could you elaborate why you would like to change the npm log level?

[HackAttack]

We must be free to optimise the settings for the Docker runtime and the ways Docker is used different form other platforms.

This goes against what I want as a Docker user. I want things to work the same, not differently. If certain things behave differently in the Docker environment than outside (in this case, the output from npm commands), that violates the principle of least astonishment and works against my use case for running Docker. If I want verbose logs I can specify the setting myself in my Dockerfile, but I expect the official image to have the same default behavior as the software itself, and this setting violates that expectation.

I also don't think it's appropriate to assume that a) verbose logs would always be desired on CI servers, or b) Docker is only or primarily being run on CI servers. I run Docker locally and it is unpleasant to have these logs in my console when I didn't ask for them.

[jlmitch5]

I don't have a preference on which log verbosity we use.

Would it be an improvement to have a line like:
ENV NPM_CONFIG_LOGLEVEL info # increase verbosity of log. NPM defaults to warn

So that it is obvious that is what needs to be changed if the user wants default behavior?

[jlmitch5]

Instead of the current ONBUILD RUN npm install --loglevel info

[jlmitch5]

ah, that's what @pesho recommended and what the PR ended up being submitted.

[Starefossen]

This goes against what I want as a Docker user. I want things to work the same, not differently. If certain things behave differently in the Docker environment than outside (in this case, the output from npm commands), that violates the principle of least astonishment and works against my use case for running Docker.

The purpose of Docker is consistency, not similarity to the host OS. Unless you are running Debian on your host machine the Node.js application in the Docker Container will never behave exactly the same as running it on your local machine, but it will behave the same each time you run the container (hence consistency).