Closed syabro closed 4 years ago
At the moment no, but part of the code system is also designed with filtering in mind. For example something like this:
messageFilter:
- YN0013
It shouldn't be a lot of work - just a configuration setting to add in Configuration.ts
and the filtering itself to implement in StreamReport.ts
. Do you want to give it a try?
I have one idea for you to consider about output UX. If there are many repetitive messages we can show progress indicator. But if there are say less than 5 repetitive messages, we can actually show them - imagine the situation when you want to troubleshoot one package fetching, - you might be interested in yarn decisions about it, but if there are not too many of them
We could extend the mechanism we use for the progress bar to only show the last N lines, true. My main issue with that is that practically speaking, it'll be only really used for fetch I think. Other messages are important to show 🤔
Not last N lines. All lines, but if the number of lines does not exceed N, otherwise only show progress indicator. The rationale is that last N lines might be random and not interesting. So if there are too many lines show only progress indicator. If there are very few lines - show them without progress indicator.
Guys, what's the point of showing 100500 same lines? Separate lines make sense if user wants to press CTRL+C to avoid unexpected behavior.
Is it a case for yarn?
Maybe use one line for text message and show the packages joined instead of one-line-per package?
➤ YN0013: │ These packages were not found in the cache and will be fetched from the remote registry
➤ YN0013: │ array-flatten@npm:1.1.1 accepts@npm:1.3.7 body-parser@npm:1.19.0 bytes@npm:3.0.0 bytes@npm:3.1.0 compression@npm:1.7.4
➤ YN0013: │ confetti-js@npm:0.0.15 compressible@npm:2.0.18 content-disposition@npm:0.5.3 content-type@npm:1.0.4 cookie-signature@npm:1.0.6
➤ YN0013: │ cookie@npm:0.4.0 cors@npm:2.8.5 debug@npm:2.6.9 depd@npm:1.1.2 destroy@npm:1.0.4 ee-first@npm:1.1.1 encodeurl@npm:1.0.2
➤ YN0013: │ escape-html@npm:1.0.3 etag@npm:1.8.1 express@npm:4.17.1 finalhandler@npm:1.1.2 forwarded@npm:0.1.2 fresh@npm:0.5.2 http-errors@npm:1.7.2
➤ YN0013: │ http-errors@npm:1.7.3 iconv-lite@npm:0.4.24 inherits@npm:2.0.3 inherits@npm:2.0.4 ipaddr.js@npm:1.9.0 media-typer@npm:0.3.0
➤ YN0013: │ merge-descriptors@npm:1.0.1 methods@npm:1.1.2 mime-db@npm:1.43.0 mime-types@npm:2.1.26 mime@npm:1.6.0 ms@npm:2.0.0
➤ YN0013: │ ms@npm:2.1.1 negotiator@npm:0.6.2 object-assign@npm:4.1.1 on-finished@npm:2.3.0 on-headers@npm:1.0.2 parseurl@npm:1.3.3
➤ YN0013: │ path-to-regexp@npm:0.1.7 proxy-addr@npm:2.0.5 qs@npm:6.7.0 range-parser@npm:1.2.1 raw-body@npm:2.4.0 safe-buffer@npm:5.1.2
➤ YN0013: │ safer-buffer@npm:2.1.2 send@npm:0.17.1 serve-static@npm:1.14.1 setprototypeof@npm:1.1.1 statuses@npm:1.5.0 toidentifier@npm:1.0.0
➤ YN0013: │ type-is@npm:1.6.18 unpipe@npm:1.0.0 utils-merge@npm:1.0.1 vary@npm:1.1.2
But if there are say less than 5 repetitive messages, we can actually show them - imagine the situation when you want to troubleshoot one package fetching
Too complicated and why five or not ten or twenty? Maybe
--verbose-fetch
option to show text?Was https://github.com/yarnpkg/berry/pull/914 reverted? Or is it a regression? I'm getting around 7K of YN0013 messages using Yarn 2.1.1.
Not reverted, and we don't have a regression as far as I'm aware. Feel free to open an issue with the relevant info (including screenshots, and potentially investigating yourself why would the logs be printed) if you believe this comes from Yarn.
I'm observing this on CI, which does not allocate a TTY. On the local machine it works as expected and only shows 5 messages at a time. So it seems to work as expected.
# Allocates pseudo-tty and only shows 5 messages.
docker run -t --rm node:14 bash -c 'mkdir test && cd test && npm init -f && yarn set version berry && yarn add react-native'
# Does not allocate a pseudo-tty and shows ~4K messages.
docker run --rm node:14 bash -c 'mkdir test && cd test && npm init -f && yarn set version berry && yarn add react-native'
Which CI? We have a CI mode under which only a summary is printed. Perhaps your CI isn't well detected?
iirc docker doesn't count as a CI, try setting CI=true
It is a Docker container which is started manually on Azure Pipelines, so it is expected that it is not detected as CI. Setting CI=true
works like a charm. Thanks for the hint @merceyz!
For anyone coming here from search, this was resolved in #1907 via logFilters
More specifically, add this to .yarnrc.yml
:
logFilters:
- code: YN0013
level: discard
I don't like 100
YN0013
messages withcan't be found in the cache and will be fetched from the remote registry
Can it be hidden somehow by default?