Get Your TypeScript Coverage Report

#typescript #tutorial #webdev #tooling

Here is something I’ve been meaning to do for quite some time now -
You see, you start a project using TypeScript (TS) or maybe migrating an existing code base to TS, and would like to know how well your project is “typed”, and that, so you can be sure that when you’re about to refactor your code you’ve got TS to protect you (along with testing of course, right? 😉).

How do you do that?

Turns out there are tools for that and one of them is called typescript-coverage-report by Alex Canessa and I’m going to give it a try now and implement it in my Pedalboard monorepo.

Let’s get started!

Hey! for more content like the one you're about to read check out @mattibarzeev on Twitter 🍻

I will start by implementing it in a single package within my monorepo and see the value I gain from it. The package I choose is the stylelint-plugin-craftsmanlint which is a stylelint plugin (as the name suggests, don’t know why I wrote that… 😅)

Starting with the instructions on the coverage npm package page:

yarn add -D typescript-coverage-report

Next we add the npm script to the package.json file so that we can run the coverage:

"scripts": {
       ...
       "ts-coverage": "typescript-coverage-report"
   },

Now let’s run it

yarn ts-coverage

Hey, that’s not bad - here is the summary coverage page for my package:

And it also generated an HTML report:

Putting the jest.config.ts file aside for a sec, I see that my test there has low coverage. Let’s drill into the report (a part of it) in the image below:

Ok, that’s nice, I can see where the types are missing, but hovering on them does not tell me what exactly the issue is (like jest unit testing coverage does), but I guess you can say that the issue is “you don’t have a type for this”, right?.

Just to make sure this all works, I will try to fix one of the issues and run the coverage again to make sure it is no longer there - What is the require statement for lint doing there? Did I do that? Oh my, let’s convert it to an ESM import and run the unit tests again to make sure all still works:

// const {lint} = require('stylelint');
import {lint} from 'stylelint';

Yes, they all still pass. Now let’s run the TS coverage tool to see if it had some effect over it, and… yes! Wow, we’re now at 98.97% coverage:

But… we still have an issue there. Where is it?

Hmm… interesting. jsonRule does not have a type to it. Fixing:

const jsonRule: ConfigRules = JSON.parse(`{
…      
}`);

And now we have 100% coverage. Cool!

As of that jest.config.ts file, I think we can ignore it by introducing a typeCoverage property in our package.json file (though I'm too keen about adding configurations in the package.json file. I much prefer an .rc file):

"typeCoverage": {
       "ignoreFiles": [
           "jest.config.ts"
       ]
   },

Now our TS code coverage report is all good and looks like this:

Nice 🙂

All-in-all typescript-coverage-report looks like a really cool tool for finding out how well your project is “typed”. It can be integrated as a commit hook or even some code checkers as part of your GitHub actions (hmm… here’s a neat idea for my next post 😉).

You can check out the entire code on the Pedalboard monorepo.

Hey! for more content like the one you've just read check out @mattibarzeev on Twitter 🍻

Photo by Fallon Michael on Unsplash