Skip to content
TaskBounty
Sign in
Back to Blog

The JS/TS Coverage Index: public test coverage signals for popular JavaScript and TypeScript repos

Eliott Reich, founder of TaskBounty6 min read
test coverage
javascript
typescript
open source
testing
mutation testing

The JS/TS Coverage Index

Coverage is a map, not a grade. We built a public index of test coverage signals across popular JavaScript and TypeScript repos to make that map easier to read.

You can browse it here: task-bounty.com/coverage-index.

Why we built it

If you want to know the test coverage of a repo you do not maintain, it is oddly hard. Some projects publish a Codecov or Coveralls badge in the README. Many do not. The ones that do are often the ones already proud of the number, so what you can see from the outside is a skewed slice of reality.

We measure coverage for a living (we are a JavaScript and TypeScript coverage service), so we had the pieces lying around to do this properly: clone a public repo in a sandbox, install its dependencies, run its own test suite, and read the real number. We pointed that at a curated set of recognizable JS/TS repos, added the ones that already publish a public provider number, and put it all on one page.

One rule, strictly: we never fabricate a number. If we do not have a real measured value or a real public-provider value, the repo is labeled "no public signal." That label is a finding in itself, not a gap.

Coverage is useful, but imperfect

Before the numbers, the caveat that the whole thing rests on.

A coverage percentage tells you which lines ran while the tests ran. It does not tell you whether the tests would notice if those lines started doing the wrong thing. You can hit a high number with tests that execute a lot of code and assert almost nothing. You can also have a modest number sitting on a small, sharp suite that catches real regressions.

So coverage is a starting map of where tests do and do not reach. It is not a quality score, and it is definitely not a grade for the team. Read it that way and it is genuinely useful. Treat it as a verdict and it will mislead you.

Methodology

Three kinds of signal feed the index, labeled honestly on each row:

  • Measured. We cloned the repo in an isolated sandbox, installed deps (pnpm, yarn, or npm, whichever the repo uses), ran the project's own coverage command, and parsed the result. This is a real number from the repo's real suite.
  • Public provider. The repo publishes a current Codecov, Coveralls, or SonarCloud number, and we read that.
  • No public signal. We could not get a trustworthy number without guessing, so we say so. Common causes: a large monorepo that does not publish per-package coverage, a project that runs coverage privately in CI but exposes nothing, or a library whose test setup is unusual.

JavaScript and TypeScript only. That is what we measure today, so that is all we put numbers on. We do not estimate, and we do not extend this to ecosystems we cannot actually run.

What we found

The index sorts into three shapes, and all three are interesting.

Repos below 80 percent. A number under 80 is not a sign of bad engineering. On a mature library it usually means there are specific files, often the gnarly edge-case paths, where a few well-aimed tests would cut real risk. The useful output is never the percentage, it is the short list of files where a missing test is most likely to let a regression through.

Repos above 80 percent. Plenty of well-known utilities and frameworks sit high, and a few are effectively maxed out. Worth noting that a high number here is earned by projects that have invested in tests for years. It is also the ceiling, not the point. Past a certain level, the next percent costs more than it returns, which is exactly why 80 is a reasonable line to verify against rather than chasing 100.

Repos with no public signal. This was the most common result among the biggest names, and it is the one people misread. Several of the most-used JS/TS projects in the world expose no obvious public coverage number. That does not mean they are poorly tested. Large monorepos like the framework cores often run coverage internally and simply do not publish a single headline figure. The honest reading is narrow: from the outside, you cannot tell. That is a statement about visibility, not quality.

Why line coverage alone is not enough

If line coverage only tells you what ran, what tells you whether the tests are any good?

The sharper question is not "what is the number" but "which risky paths are untested, and would the tests actually catch a break." Two tools get you closer than a percentage:

  • Critical-path testing. Coverage on the boring, stable code that never changes is low value. Coverage on the paths that move money, handle auth, or parse untrusted input is where a missing test actually hurts. A good map weights those paths, it does not treat every line as equal.
  • Mutation testing. This is the strongest "are these tests real" signal we know of. A mutation tool deliberately introduces small bugs into the code and checks whether the test suite fails. If you break a line and every test still passes, that line is covered on paper and unprotected in practice. Line coverage asks whether code ran. Mutation testing asks whether a broken change would be caught. Both matter, and the second is the one most people skip.

We run mutation testing as part of our own work to verify the tests we write actually catch injected bugs, not just move the coverage number. It is the difference between a map that shows roads and a map that shows which bridges hold weight.

Check your own repo

The index is a curated set, but the checker behind it works on any public JS/TS repo. Paste a repo and it returns the measured number plus the files where tests would reduce the most risk: task-bounty.com/coverage-check.

If you maintain one of the indexed repos and the number looks off, there is a "challenge this number" link on every result page. Coverage setups vary, especially in monorepos, and we would rather fix a reading than defend a wrong one.

A note on private repos

Everything in the index is public, by design. We never publish private repo data, never publish a private repo name without written approval, and the before-and-after improvement pages are limited to repos that explicitly opted in. If you want your own private number, the private check runs read-only in a sandbox and keeps the numbers, not your source.

Coverage is a map. The index is our attempt to draw a clearer one for the JS/TS world, with honest labels where the map runs out. Check a public repo, or run a private coverage audit, at task-bounty.com/coverage-check.