new spinner is terrible UX

[dominictarr]

The rule of silence, as it's usually stated, is that "if a program has nothing surprising to say, is should say nothing at all"

Looking at this the reverse way, if something surprising HAS happened, then you must inform the user

A progress bar is nice, because it gives the user some idea about how long they will be waiting for, even log output can work in this way... even non-programmers learn to recognize patterns in the log output at boot, or the sound that the modem makes when it's about to successfully connect)

But the only thing that a steady spinner communicates is that the computer is still operating... And worse, it appears to be trying to communicate, but the movements mean nothing.

Really a spinner is the UX equivalent to when you are on hold, and you get hold music plus a message with "thank you for waiting, you are a valued customer".
An empty platitude, that instead of making you feel reassured, actually makes you feel more ignored.

A spinner that does not mean anything is worse than no output at all.

What would be acceptable:
If the spinner only moved when something actually happened (say, if it moved when ever the old log would have output a line) then, it's much more reassuring to the user - if it changes slowly - it must be waiting - if it changes fast, then the network is good right now...

[edef1c]

+1

[refack]

👎 I love it. Even submitted a PR to improve it. But it's incompatible with other packages that play with cursor position such as mocha:

[mantoni]

+1 for (at least) not showing the spinnter when running scripts, especially npm test and npm start

[xaka]

+1 as it makes Travis CI and Capistrano to generate huge logs. I'd either disabled it completely by default or change it back to previous version. Everything that changes cursor position (including \r) is bad for automation. As an option you could consider using infinite dots as an indicator of activity.

[mgol]

I submitted #5363 for not showing the spinner in npm scripts like npm test.

[nullivex]

+1 this is driving me nuts on Windows as well. Its not compatible with any of my terminals and the old format was just perfect.

[timoxley]

It'd be nice if the spinner could be toggled on off as the install is running (without losing previous log output) via hotkey.

[timoxley]

i.e. press the hotkey to take a peek at what's actually happening.

[nullivex]

It would be okay if it worked properly in windows but I dont see the point in the work required to make it cross OS compatible at least just disable it in windows by default?

[isaacs]

npm config set spin=false will disable it.

"The computer is operating" actually is relevant information. When the loglevel is set too low, people frequently think that npm is "hanging" when in fact, it's just fetching a lot of stuff. When it's set to include http, people complain about it being too noisy.

This is the reason why, as infuriating as it might be, "your call is important to us" is much better UX than silence. Silence would not tell you that you're still connected.

A more informative progress indicator would be better, no one is arguing that point. But that requires much more extensive work on the install process, which is planned, but will take a while.

[nullivex]

@isaacs Thanks for the config option at least it will make it tolerable on Windows.

You are correct on people thinking its hanging. Its just that this particular solution doesn't really work well for everyone at the moment so it is frustrating for those of us that don't have terminals capable of displaying the spinner correct and having it on by default.

[vohof]

👍 I'd prefer seeing the http messages than a spinner.

[nullivex]

Why not both? Or a percentage on the HTTP request?

On Tue, Jun 3, 2014 at 4:20 PM, Cyrus David notifications@github.com
wrote:

[image: 👍] I'd prefer seeing the http messages than a spinner.

—
Reply to this email directly or view it on GitHub
#5340 (comment).

eSited LLC
(701) 390-9638

[dominictarr]

@isaacs a really simple fix that would still be slightly meaningful would be to have the spinner tick when the the log would have output something. then you can look at it and distingiush between working and waiting. A progress bar is very difficult in this case, because does not know how much work it will be upfront.

The "thank you for waiting" is patronizing, hold music is enough to let you know you are still connected.
Maybe the CLI tool equivalent would be animated ascii art...

[75lb]

with npm start the typical goal is to launch a server, so I assumed the spin would cease once my goal was met.. but the spin persists.. did my server launch successfully? the spin says "no" but it seems up.. i'll write a "server is up, disregard the spin" message to the console.

[cnvo]

My suggestion would be to use dots.

"..." from 1-3
.
..
...

and loop. No more than 3.

[medikoo]

+1

I just upgraded to latest node, and saw this.

This spinner is a terrible idea, breaks most scripts I use.

To my understanding this should be provided by configured scripts and not by script runner which now just breaks output of every single script it manages.

UPDATE: Glad to see it fixed

[tjwebb]

Actually breaking things is worse UX than merely seeming to break things. Surely though you have a closer read on the community pain points than I; if people have been clamoring for more spinner, I must have just missed that discussion by having not searched for it.

npm is very verbose by default already (in a good way). It behaves very similarly to apt-get in output format, and to the extent they've also seen requests for ASCII spinner, I'm glad they've chosen to not implement it. Foaming -\|/-/ all over the place seems like an over-correction.

+1 thanks for npm config set spin=false.

[razzmatazz]

👍 silence is golden, unless there is something I should know

[rlidwka]

It behaves very similarly to apt-get in output format

apt-get prints out 1 line per package, npm at http level usually prints out 4 lines. So apt-get is a bit less verbose.

[matejkramny]

👍
Is there option to make it more verbose? I know there's -v but thats too verbose :P

[kumarharsh]

npm config set spin=false just hides the spinner, but shows nothing in it's stead.
How do I get back the logs output?

Also, it is really useful seeing the logs to see which command is breaking, or where did the error come while building some package. The npm-error log which is generated at the end is not always very useful, or atleast, takes a much higher effort to understand sometimes. Is there a way to turn on the logs?

[mgol]

@kumarharsh

npm config set spin=false just hides the spinner, but shows nothing in it's stead.
How do I get back the logs output?

npm config set loglevel=http. Generally, read https://www.npmjs.org/doc/misc/npm-config.html, those options can be set permanently via npm config set.

[kumarharsh]

Thanks for that info !

[plato-cambrian]

+1 how frikkin irritating
Edit: Suggested fix, just set the default to spin=false and leave the command there for ppl who want to reenable it

[pgorsira]

+1

[rick-kilgore]

+1 - running scripts via npm and saving or parsing output does not work well with the spinner.

sorry, didn't see the workaround in this thread before I posted - setting spin=false works for me

[DomT4]

The spinner is supremely irritating. I appreciate knowing that npm hasn't started hanging on me, but can we not achieve this in a slightly better format that an arbitrarily spinning /. A loading percentage would be more useful, ... would be more aesthetically pleasing. The spinning / just manages to be irritating.

[othiym23]

One way or another, npm will have an improved progress display before the end of the year. The current spinner is roughly about as good a job as we can do with the current install algorithm. Once we've figured out one-step full dependency tree resolution, it gets closer to being possible to do things like display the percentage complete / progress meters / rough estimates of time to completion a la apt-get. Until then, though, the spinner is what we've got.

[rlidwka]

The current spinner is roughly about as good a job as we can do with the current install algorithm.

Right now you can't estimate how many http requests you've got to do.

But you can show user an exact amount of http requests already made, and progress of each pending request. And it is possible to do it with minimal changes to current npm code.

[othiym23]

@rlidwka I'm disinclined to put too much time into this, because I know that all the code related to this is going to change a bunch in the very near term (and because we have a lot to do along the way). If you feel strongly enough about this to submit an upstream patch extracted from yapm, we can probably work together to get it landed, but it's not on my list of things to do before I get to multi-stage install.

[xaka]

Guys,

While working on improving npm please keep in mind that there are tools
like Travis CI, Jenkins, etc. that do run "npm install" which means you
could end up with bloated log output from those tools simply because people
knew nothing about "--no-spin" option and new spinner was introduced with
no announcement. When open such logs you see thousands of lines with just
one "/" character. The point is we always need an option to disable/change
behavior when we want to run npm in non interactive environment (i.e. no
terminal).

On Tue, Aug 5, 2014 at 12:37 PM, Forrest L Norvell <notifications@github.com

wrote:

@rlidwka https://github.com/rlidwka I'm disinclined to put too much
time into this, because I know that all the code related to this is going
to change a bunch in the very near term (and because we have a lot to do
along the way). If you feel strongly enough about this to submit an
upstream patch extracted from yapm, we can probably work together to get
it landed, but it's not on my list of things to do before I get to
multi-stage install.

—
Reply to this email directly or view it on GitHub
#5340 (comment).

[rlidwka]

@othiym23 , I'm working on it, should be easy enough.

@xaka , npm disables spinner when stdout is not TTY, so this "/" character should not appear in logs anywhere.

[plato-cambrian]

My preference is:
Disable the spinner by default
Allow granular controls for:
npm install npm test and any npm run * script.

On Tue, Aug 5, 2014 at 7:00 PM, Alex Kocharin notifications@github.com
wrote:

@othiym23 https://github.com/othiym23 , I'm working on it
https://github.com/rlidwka/yapm-progress, should be easy enough.

@xaka https://github.com/xaka , npm disables spinner when stdout is not
TTY, so this "/" character should not appear in logs anywhere.

—
Reply to this email directly or view it on GitHub
#5340 (comment).

[xaka]

Alex,

I wonder if it was fixed recently because about a month ago it's exactly
what was happening to all of my builds using Travis CI. I had logs full of
lines with only one well known character on each and only "--no-spin"
helped to solve it.
On Aug 5, 2014 6:00 PM, "Alex Kocharin" notifications@github.com wrote:

@othiym23 https://github.com/othiym23 , I'm working on it
https://github.com/rlidwka/yapm-progress, should be easy enough.

@xaka https://github.com/xaka , npm disables spinner when stdout is not
TTY, so this "/" character should not appear in logs anywhere.

—
Reply to this email directly or view it on GitHub
#5340 (comment).

[othiym23]

@xaka: The spinner was changed to only run on fetches in npm@1.4.15.

[empiricalthought]

Can the isTTY property of process.stdout be used to determine when the spinner/color/progress blinkenlights should be displayed? http://nodejs.org/api/process.html#process_process_stdout

[othiym23]

@empiricalthought char-spinner, which is what npm uses to implement the spinner, does this already. But @iarna has a different solution in mind as part of her multi-stage install project: real progress bars! Stay tuned.

[empiricalthought]

Ah, can it be added to color output as well then? (Possibly not related to this issue.)

[antwonlee]

please take the spinner away...... 🚑

[KenanY]

@antwonlee Is npm config set spin=false and spinner-on-fetches-only not sufficient?

[iarna]

Improvement to this is going to be implemented in #6911. As such, I'm going to close this ticket so that future discussion can happen around the actual implementation.

[iarna]

This is going to be addressed (hopefully) by #6911, so I'm going to close this ticket so we can move new discussion there.