Disable progress

[ldabiralai]

Summary

I've added --disable-progress as it's useful to be able to turn off progress bars on CI environments (like CircleCI) otherwise while using yarn to install packages you have a lot of unnecessary info cluttering the view:

It also disables progress for the spinning progress icons.

Test plan

I've added a test to console-reporter.js to ensure the feature works as desired.

Let me know what you think, thanks!

[inikulin]

I believe it can be automatically disabled in CI environments without introduction of new option, see: https://github.com/watson/is-ci

[ldabiralai]

Thanks @inikulin but using that would limit this too much, in my opinion.

[inikulin]

Thanks @inikulin but using that would limit this too much

Can you elaborate, please?

[ldabiralai]

@inikulin Sure. I don't think we should force hiding it on CI, nor should it be an option only on CI. I think it should be an option that people can choose if they want to use it. In the same way npm set progress=false works.

[samccone]

👍

[sindresorhus]

The CLI convention is to use no- for negated flags, so this should be --no-progress.

[sindresorhus]

I don't see the point of a flag when it can be handled automatically for the user.

[ldabiralai]

I felt the flexibility the current implementation offers is good.

Yarn isn't widely adopted in CI yet, so everyone will be manually running yarn. I didn't see it as a big cost to add a flag if you wanted to disable the progress bar. As it wouldn't require other changes to your CI config files.

Can change it though if the consensus is we want it to be restricted to CI as well as forced.

[inikulin]

Yarn isn't widely adopted in CI yet, so everyone will be manually running yarn. I didn't see it as a big cost to add a flag if you wanted to disable the progress bar. As it wouldn't require other changes to your CI config files.

So we'll have:

1. Figure out that yarn output is broken on your CI.
2. Try to find recipes to workaround it in documentation/issues.
3. Finally find `--no-progress` option
4. Modify your CI configuration files and commit them or issue a PR and go through review process.
5. Get it work as expected.

VS

1. It works properly instantly.

I'm not against an option. We can keep it, but disable progress on CI by default. That's why I ask you a question in #1190 (comment): are you aware of any scenarios there disabling progress on CI can be harmful?

[ldabiralai]

Fair enough, seems a number of people like it that way too! I'll make the change to add https://github.com/watson/is-ci and keep the option for non-ci too.

[inikulin]

Seems like console reporter tests require some rework now

[sebmck]

We should just have detection, I'm against having another flag for this.

[daveadams]

There are cases besides CI or whatever automated cases you may think of where users may wish to avoid the cutesy terminal-hack output. I'm not sure I understand the opposition to a CLI option for this. There's a CLI option for avoiding emoji.

"Yarn isn't widely adopted in CI yet, so everyone will be manually running yarn"

I am currently deploying yarn in a deployment pipeline that is not covered by https://github.com/watson/is-ci.

[ldabiralai]

Thanks Dave, I'm of the same opinion. Nothing bad about a bit of flexibility.

Will take some time over the weekend to take a look at the test failures. 😃

[designfrontier]

I am with the two comments above me. Not all CO is going to be covered by is-ci. If the argument is to make it easy do both. Detect when possible and provide a flag for users not in detectable ci environments.

[sebmck]

If you don't want nice terminal output then don't report that you're a TTY when executing yarn. An explosion of user flags is not desirable. This PR will only be accepted without the CLI flag.

[daveadams]

I can't reconcile the pushback here with #922 from a week ago. There are always going to be situations where "nice" output is undesireable even if it's running in a TTY. In particular I'm thinking about accessibility use cases, where TTY functionality is often useful, but for which animated progress spinners are problematic. But also, alas, purchased tools that capture output using a TTY and don't give you the option.

[jakebasile]

Adding CLI switches to customize output isn't uncommon. Examples

• curl --silent
• apt-get --quiet
• git --no-color
• rpm --quiet
• jq --color-output
• nom --no-color

Sometimes people want to override how output is displayed irrespective of things the utility can automatically detect. All the fancy output here is great if you like eye candy, but some people just want (or need, as @daveadams pointed out wrt accessibility) to strip that stuff out.

[ldabiralai]

I've fixed the tests. Progress is disabled on CI and the --no-progress flag is still present.

I don't think we should be removing the flag as with the previous two comments, and there also seems to be demand for it in #1340 #788 #728

[wclr]

@kittens

This PR will only be accepted without the CLI flag.

What should it be then?

I vote for config option ala yarn config set progress=false this is more desirable in my view, especially when working with containers. As I see it is not in the PR, should there be created an issue for that?