Add a setting for collecting coverage

[stephtr]

Jest/#5836 enabled switching whether or not Jest should collect coverage information by a workspace attribute. This PR adds a setting to control that attribute.

Points to talk about:

• I defaulted the (boolean) setting to null, since supplying false would add the --no-coverage flag.
• Toggling coverage overlay may not display the overlay if collectCoverage isn't true, it therefore shows a warning message in that case. That behavior isn't perfect if collectCoverage has been kept at null and the jest command/config has been modified to nevertheless collect the information.
• The same is true for showCoverageOnLoad, but without a warning message.

An alternative would be that, additional to the coverageCollect switch, the setting could be temporarily overwritten when toggling the coverage overlay.

By the way: Sorry that I accidentally pushed these commits to the master branch, that shouldn't have happened, but I had my local branch tracking upstream instead of origin.

[coveralls]

Pull Request Test Coverage Report for Build 393

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 3 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.2%) to 75.432%

---

Files with Coverage Reduction	New Missed Lines	%
src/JestExt.ts	3	53.13%

Totals
Change from base Build 391:	-0.2%
Covered Lines:	641
Relevant Lines:	811

---

💛 - Coveralls

[connectdotz]

just to play devil's advocate, why do we want to force users to learn yet another coverage flag if they can already put it in their settings (like jest.pathToJest) or package.json script with --coverage...?

[stephtr]

One concrete use case would be if the default value of pathToJest would be fine for a project, one doesn't have to manually add the path to jest.
We furthermore don't force the user to use the new setting (maybe I should remove the warning message), he could still specify the --coverage flag within pathToJest.
I think it's generally cleaner to separate the path setting from the executable's extra arguments (like pathToConfig, which can be also supplied via a setting or as a flag).

[connectdotz]

I think it's generally cleaner to separate the path setting from the executable's extra arguments (like pathToConfig, which can be also supplied via a setting or as a flag).

I like this idea a lot better, and I think it will probably give us more bang for the buck in the long run... But can you give us a little bit more background on what exactly the problem we are trying to solve with this PR?

[stephtr]

There's no problem with the current status, it would be just a simplification/enhancement. But maybe it would be better to continue the discussion in #226.

[connectdotz]

oh i see, will do

[seanpoulter]

I prefer having folks configure Jest separate from configuring the UI. Jest has great documentation. If anything, I’d want to help change the config for users.

[stephtr]

In what direction would you then like #226 to go?

[seanpoulter]

I'm not sure @stephtr and while it's a good conversation to have I'd urge us to focus on our core functionality instead of the nice to have issues. While trying to fix a few regressions we've introduced in the last few weeks I seen all of these:

• test decorators not updating properly
• inline error messages that aren't being cleared
• colour escape codes appearing in messages
• the status bar message that hangs
• inline error messages in the wrong spot

I'll skim #226 and give my two cents.