Repository: TypeScript
Issue: Design Meeting Notes, 6/18/2024
Labels: Design Notes


# Coverage Reporting

https://github.com/microsoft/TypeScript/pull/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 https://github.com/microsoft/vscode/pull/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

https://github.com/microsoft/TypeScript/pull/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

https://github.com/microsoft/TypeScript/pull/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.