Add coverage to packages beyond contracts

[rajivpo]

Description
Added the ability to surface test coverage metrics for all relevant packages. This is the first of hopefully a few PRs I want to submit to improve test coverage across various packages (probably starting with core-utils as it's the easiest) and figured having the ability to surface where coverage is lacking in an automated fashion would be helpful for development.

I've also seen repos hook up coverage numbers to their homepages, and if this is a desired feature, I'm happy to investigate. There's also probably an opportunity to ensure that coverage isn't decreasing as a pre-commit hook, and am happy to spend time implementing that would be helpful.

Additional context

Metadata

[changeset-bot]

🦋 Changeset detected

Latest commit: acccf17

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@eth-optimism/batch-submitter	Patch
@eth-optimism/core-utils	Patch
@eth-optimism/data-transport-layer	Patch
@eth-optimism/message-relayer	Patch
@eth-optimism/smock	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[tynes]

Hey @rajivpo thanks for the PR! Do you mind explaining a bit about how nyc is used? Perhaps a blurb in the top level README. It looks like this PR adds the ability to run nyc against each of the different packages - it would be nice to have its output show up in the PR or something like that. I believe we use codecov already for the contracts, it looks like there is an integration: https://github.com/istanbuljs/nyc/blob/master/docs/setup-codecov.md

[tynes]

Do you also mind squashing your commits into a single commit?

[codecov-commenter]

Codecov Report

Merging #1297 (8dc7276) into develop (1f1fff9) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop    #1297   +/-   ##
========================================
  Coverage    86.05%   86.05%           
========================================
  Files           49       49           
  Lines         1936     1936           
  Branches       307      307           
========================================
  Hits          1666     1666           
  Misses         270      270           

Impacted Files	Coverage Δ
...c-ethereum/libraries/standards/L2StandardERC20.sol	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33cb902...8dc7276. Read the comment docs.

[rajivpo]

I figured i could remove this entire block now that there's coverage across all ts-packages, but if there's a good reason to keep this, happy to add back in.

[rajivpo]

@tynes does this suffice?

[rajivpo]

Should have a bit more time this week - will continue adding to coverage to packages

[elenadimitrova]

Thanks for the contribution! In line with what @tynes said above, can we also add the Codecov report run on the respective package readme, same way we do for contracts https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts
Also we need to add checks for the branch coverage to CI for each package and set it to not drop below what we currently have. I think improving coverage after that can be done in separate PRs to make this and subsequent work easier to review.

[elenadimitrova]

@rajivpo heya, just looking at the last commit and seeing that codecov is now just on the main readme, as opposed to what we agreed above which was to add the Codecov report run on each of the respective package readme. Basically I personally think that coverage per package is more meaningful than overall monorepo coverage. Sorry if my comment above was what confused you!

[rajivpo]

oh okok yes this makes a lot more sense, I think this can be done with flags via codecov, but will need to double check

[rajivpo]

Given how messy this is, I'm going to close this out as a much cleaner version of this is in development in #1412