Add code coverage reporting

[dleve123]

Code Coverage Info in CodeCov

Anyone within the Artsy org should be able to sign into Codecov via Github-auth to get more granular coverage statistics: https://codecov.io/gh/artsy/positron

Code Coverage Into in Console Output

---

Supersedes #1854 (wanted to rename branch)

https://artsyproduct.atlassian.net/browse/PLATFORM-1136

Problem:

One part of the product health matrix story spike is code
coverage for each service. However, there is no pattern at Artsy for
measuring code coverage for Javascript applications.

While there are existing tools out there for tracking and reporting code
coverage, such as istanbul.js, coveralls,
and codecov, the complexities:

1. A multi-runner test suite (jest and mocha), and
2. A Circle CI -> Docker -> Docker test runtime

have resulted in a tough problem to solution around.

Solution:

After spending a lot of time trying to get Coveralls instrumentation to
work, we pivoted to using Codecov. At a high level, this commit does the
following:

1. Updates our calls to jest and mocha to write code coverage
   information to a .nyc_output directory (default for nyc/istanbul)

2. Manipulates the jest coverage information to be compatible with
   mocha coverage information via a JS script. See motivating GH
   issue.

3. Merges the jest and mocha coverage information together using the
   nyc CLI

4. Introduces a bash executable provided by codecov to instrument the
   merged information to codecov

Co-authored-by: Kieran Gillen [email protected]

[damassi]

@dleve123 - can we add a screenshot of example output from the CLI within the top description?

[damassi]

Why this line instead of renaming the obj arg result?

[damassi]

This looks super readable (not suggesting a change) but could also do

error => error && console.log(error) 

Also, by the way this is formatted I can tell your editor is missing a Prettier integration :) which we use for all of our JS repos based on configuration located here.

[dleve123]

@damassi Is Prettier compliance enforced during CI? I think style checking would be a bit more robust if we asserted upon a certain style during CI, instead of assuming that everyone use an editor that is integrated with Prettier.

[damassi]

On all of our JS repos we typically run things like prettier during a pre-commit hook which is defined here -- not too sure why this didn't run?

[dleve123]

It's possible that I ran a --no-verify when committing at times -- that probably explains it :)