v25.1.0 text reporter generates to much white space

[folderol4]

🐛 Bug Report

Testing the output from the text reporter between v24.9.0 and v25.1.0 I noticed two changes in behavior that make the report harder to read. It maybe an istanbul issue, but I wanted to start here.

1. The uncovered line #s are no longer truncated with ....
2. If the number of uncovered line #s is very long the value will wrap. If 1 file causes 5 line wraps then every file that is reported is given the same 5 line wraps. Consistency is usually great, but in this case it results in the report being mostly white space and harder to read.

To Reproduce

• Have a file that reports many many individual uncovered lines (100 or so individual uncovered lines should work).
• Have 10 or so other files that have minimal to no uncovered lines.

Steps to reproduce the behavior:

• Run the tests with the text reporter turned on.
• Notice the huge gaps in between each file with minimal to no uncovered lines.

Expected behavior

The number of lines to wrap for each file in the text report should be calculated for each file and not use the largest line wrap count found.

envinfo

  System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
    Memory: 943.94 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.14.1 - /usr/local/bin/node
    Yarn: 1.19.1 - /usr/local/bin/yarn
    npm: 6.13.4 - /usr/local/bin/npm
  Managers:
    Homebrew: 2.2.1 - /usr/local/bin/brew
    pip3: 9.0.1 - ~/.pyenv/shims/pip3
    RubyGems: 3.0.3 - /usr/bin/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 4.2.1 - /usr/bin/gcc
    Git: 2.19.1 - /usr/local/bin/git
    Clang: 1100.0.33.17 - /usr/bin/clang
    Subversion: 1.10.4 - /usr/bin/svn
  Servers:
    Apache: 2.4.41 - /usr/sbin/apachectl
  Virtualization:
    VirtualBox: 6.0.14 - /usr/local/bin/vboxmanage
  IDEs:
    Nano: 2.0.6 - /usr/bin/nano
    Vim: 8.1 - /usr/bin/vim
    Xcode: /undefined - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.13.6 - /usr/local/go/bin/go
    Java: 10.0.1 - /usr/bin/javac
    Perl: 5.18.4 - /usr/bin/perl
    PHP: 7.3.9 - /usr/bin/php
    Python: 2.7.15 - /Users/michael.smith/.pyenv/shims/python
    Python3: 3.5.7 - /Users/michael.smith/.pyenv/shims/python3
    Ruby: 2.6.3 - /usr/bin/ruby
  Databases:
    SQLite: 3.28.0 - /usr/bin/sqlite3
  Browsers:
    Chrome: 79.0.3945.130
    Firefox: 72.0.1
    Safari: 13.0.4

[SimenB]

This is a change in istanbul-reports@3 yeah, so you should open up an issue over there 🙂

EDIT: or at least I think so - could you include screenshots of before and after?

[SimenB]

No, this is Jest's fault. We try to measure the width of process.stdout.columns, but fallback to Infinity, which causes the wrapping. This was done in #9192 due to the default behavior cutting the filenames, which I thought looked odd.

https://github.com/facebook/jest/blob/cdce184c549c17ac017253101dbeeee071bd4449/packages/jest-reporters/src/coverage_reporter.ts#L108

Will try to come up with a better solution. It's somewhat weird process.stdout.columns isn't picked up though, it shouldn't really wrap

[SimenB]

@michael-smith-tanium what do you get if you run node -p process.stdout.columns in your shell?

[folderol4]

Sure. Would you still like before and after screenshots?

➜ git:(update-jest-deps) node -p process.stdout.columns
202

[SimenB]

Would you still like before and after screenshots?

Yes please 🙂

Super odd it says 202 but is not limited to it... What happens if you remove the maxCols from node_modules/@jest/reporters/build/coverage_reporter.js? Just remove the entire {maxCols: process.stdout.columns || Infinity}. Istanbul itself should default to 80