Coverage Reporting

#58850

• C8
  • Coverage system that wraps V8, the JS engine Node uses.
  • We currently have a task like this where you can run npm tests -- --no-lint --coverage.
  • Problem: when you bundle our entire codebase with esbuild, the file is huge. The built-in tools for C8 don't work well for processing a coverage report on TypeScript.
• Monocart: a different preview tool that not only can preview the entire produced file, but can work with sourcemaps and give details on branches that are or are not hit.
• Also has an output mode for codecov, a service to track code testing coverage.
• Probably don't want to have the comment that says "your coverage has fallen!" and gates merging, but we do want a coverage report.
  • Downside: it makes CI run slower (doubles it!).
• Would be great to figure out "which tests rely on a given branch executing?"
  • VS Code might be exploring this with API: Attributable Test Coverage vscode#212196
• Why are we doing this if we don't want to actually make it visible?
  • Good question.
  • We have >97% coverage of the checker, but many many uncovered branches.
• We want to wait on ways to make this all run faster before it's in CI - but first let's add an optional peer dep to c8 so people can run it locally.

Knip

#56817

• Utility to flag down functions not used outside the file, drop unused files, and drop utilities that are not used but also not exported as part of the public API.
• Make exceptions by adding a /** @knipignore */ tag to the preceding comment.
• Last time we talked about this, wasn't there an installation time delay?
  • Yes, but since then knip has shaved down its dependency tree.
• What about running time?
  • About 7s - not bad.
  • We're thinking of just doing it in CI.

@internal Tagging

• Basically a way to formally encode what --stripInternal is supposed to do, and say it only applies to JSDoc comments.
  • Allows you to write // Do not add an @internal tag to the next declaration, since TypeScript will now consider that unrelated.
• With --stripInternal, we've always said "it has bugs, ehhh, arguable behavior."
• This is a way to make it more formal - or at least more predictable.
• Does this add overhead because we'd now start to ask for JSDoc comments in emit.

More "Primitive" Operations in Core Utilities

#58873

• Started out with a trace where the internal some function was just a big hot path.
• Lots of operations that implicitly do more work than you might expect - but have decent alternatives.
  • || checks for truthiness, but ?? only checks for null/undefined.
  • Explicit checks for undefined are faster than truthiness.
  • for-of loops create iterators but for (let i = 0; i < arr.length; i++) doesn't.
• PR makes some changes, mostly isolated to core.ts to avoid too much noise.
• Unfortunate that there's no free lunch here. The abstraction comes at an explicit cost.