Feature request: quiet mode

[dobesv]

Describe the feature you'd like to request

Turbo has a lot of output for each build, minimum one line per package (even ones that aren't being built) plus a few lines before and after the packages. For us that's about 35 lines of output for every build, which is being run on every file change. Compare that to the webpack watcher which outputs just a few lines per change.

e.g.

• Packages in scope: ... 25 package names over 4 lines ...
• Running build in 25 packages

... 25 lines of "cache hit" ...

 Tasks:    21 successful, 21 total
Cached:    21 cached, 21 total
  Time:    4.437s >>> FULL TURBO

Some issues with this:

• If the build is in between some other stuff being built I have to scroll to find the other things being built before the turbo run
• If a build run by turbo fails, it might be in the middle of all the output (including cached success output) requiring a bit more scrolling

I have setup nodemon to run turbo when a source file changes. I also have webpack and some other watchers running to build some other things in the same console. The turbo build output totally dominates the log output, making it hard to find any errors / status messages from those other processes.

Describe the solution you'd like

It would be nice if turbo had a -q / --quiet option that would suppress some output:

1. Don't print hashes or logs for projects that were already built successfully, only logs from new or failed builds should be output
2. Don't print whether there was a cache hit or miss before each command
3. Don't print the list of scopes at the beginning
4. Reduce the end summary to a single line if something was built, or print nothing if everything was already up-to-date

Describe alternatives you've considered

None

[weyert]

Did you try https://turborepo.org/docs/reference/command-line-reference#--output-logs ?

[dobesv]

Did you try https://turborepo.org/docs/reference/command-line-reference#--output-logs ?

Yes, but it still outputs "cache miss" for each package, and the header and footer are also a fair number of lines

[dobesv]

The other thing I am increasingly noticing now that I have 50 packages is that if there's an error in a build I usually have to scroll up a page of text to see the output of the failed build. So it would also be nice to avoid printing all the "cache hit" output in those cases.

[rafaeltab]

Maybe outputting the logs to a file would be more appropriate in these cases, with 50 packages building all at once you're never going to get good insight into what is going on, especially because the logs can also get cut off in the middle of a task.

Or some other method. Maybe something similar to tmux with the windows, make a window for each task, and allow switching between the windows using arrow keys. But at that point it may be easier/a better idea to implement a vscode extension which can allow easier browsing of the logs.

[mehulkar]

@dobesv want to double confirm, does --output-logs=none not work for you?

Digging some, it looks like it was added in https://github.com/vercel/turborepo/pull/822, which was merged before this issue. I just tried and it doesn't log the hash / cache miss either, unless I'm missing something. When I try it in a small repo, I don't see the log lines you're referring to:

• Packages in scope: web
• Running build in 1 packages

 Tasks:    1 successful, 1 total
Cached:    0 cached, 1 total
  Time:    265ms 

[dobesv]

@mehulkar

I want to see the output when the task is run. I just don't want output when the task is not run. From my reading of the docs, --output-logs=none will actually suppress the output from the commands when they are run.

[dobesv]

I think if --output-logs=none would still output the logs on failure, it might be good enough. I suppose I'm not actually super interested in babel printing how many files it transpiled. When the build fails, we really do want to know why.

[dobesv]

Another option is if --output-logs=new-only didn't print the cache hit line that would definitely do the trick as well. Maybe that would actually make more sense than adding a new option. I'm not sure if people are actually interested in the details of all those cache hits.

[dobesv]

I would be willing to work on this if I have some guidance in terms of what kind of PR would be accepted here, if any.

[mehulkar]

When the build fails, we really do want to know why.

I think if --output-logs=none would still output the logs on failure

This seems reasonable to me. An alternative is --output-logs=errors-only.

I would be willing to work on this if I have some guidance

I'll bring it up at the next core meeting and give you feedback next week, unless @vercel/turbo-oss can chime in here first for general 👍🏾 or 👎🏾 so you can start implementation.

[dobesv]

--output-logs=errors-only

Seems like a good enough solution as well.

[mehulkar]

@dobesv chatted with the team and --output-logs=errors-only seems like a good direction forward (matches the hash-only and new-only options also). Happy to take a PR, thanks for waiting and for contributing! Feel free to ping me in the PR when you're able to get to it!

[dobesv]

I was looking at this a bit more and I realized there could be an inconsistency about when hashes will be shown or not between new-only and errors-only. e.g.

--output-logs	show hash	show output
full	Yes	Yes
hash-only	Yes	No
new-only	Yes	If new
errors-only	If error	If error
none	No	No

Between new-only and errors-only one always shows hashes and the other doesn't, which is kind of inconsistent.

If errors-only always showed hashes it would be consistent but wouldn't help me because I'd still get several pages of cache miss ... messages (we have close to 200 tasks that run now).

--output-logs	show hash	show output
full	Yes	Yes
hash-only	Yes	No
new-only	Yes	If new
errors-only	Yes	If error
none	No	No

This would suit my needs much better but would change the existing behavior of new-only:

--output-logs	show hash	show output
full (default)	Yes	Yes
hash-only	Yes	No
new-only	If new	If new
errors-only	If error	If error
none	No	No

Or perhaps add variants that suppress hashes on cache hit outputs:

--output-logs	show hash	show output
full	Yes	Yes
hash-only	Yes	No
output-only	No	Yes
new-only	Yes	If new
new-only,new-hash-only	If new	If new
errors-only	Yes	If error
errors-only,new-hash-only	If error	If error
none	No	No

[jameslounds]

This regexp will filter out all lines that don't start with <project>:test . turbo <command> | grep --color=never "[^:]*:<command>"

... <command>'s output

if you omit the [^:]*:, you'll get a line when the task starts turbo <command> | grep --color=never "<command>"

• Running <command> in n packages
... <command>'s output

Or, you can match the command, the "•" character Turbo uses for the first few lines, and each line of the summary at the end turbo <command> | grep --color=never -e "<command>" -e "•." -e " Tasks:" -e "Cached:" -e " Time:"

• Packages in scope: , package1, package2, ...
• Running <command>  in n packages
• Remote caching enabled
... <command>'s output
 Tasks:    m successful, m total
Cached:    o successful, m total
  Time:    0ms

Or, for displaying all uncached logs, turbo <command> --output-logs new-only | awk '!/cache hit/ && !/Packages/'

• Running <command>  in n packages
• Remote caching enabled
... <command>, and <command>'s dependents' uncached output
 Tasks:    m successful, m total
Cached:    o successful, m total
  Time:    y ms

[jtlapp]

Whatever the solution is, I would like to be able to configure quiet mode as the default, so I'm not having to type a switch with every turbo command. Could it be added to turbo.json?

UPDATE: Never mind. I see that it is available as a configuration option. Thank you!

[jtlapp]

The clean command seems to be ignoring both the CLI switch and the outputMode configuration option, always being verbose.

[tjx666]

we need this, the output still too much when run with:

--output-logs errors-only --summarize false

[anthonyshew]

From the conversation here, it's sounding like --output-logs=errors-only in #2672 satisfies the original feature request so I'll close. If you think you've got a bug or other clarifying behavioral adjustment to suggest, please open a new issue!