You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?"
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.
for-of loops create iterators but for (let i = 0; i < arr.length; i++) doesn't.
I'd have expected for (const foo of foos) {} to be highly optimized by engines at this point. Since the iterator for arrays doesn't actually do anything, I'd be surprised if most engines didn't optimize it away in this case.
I'd have expected for (const foo of foos) {} to be highly optimized by engines at this point. Since the iterator for arrays doesn't actually do anything, I'd be surprised if most engines didn't optimize it away in this case.
Still not really, a for-of-loop is still often many times slower than a for-loop, e.g. this has a difference of 10x in v8 , and 4x in jsc (curiously inlining the forOfLoop function makes v8 have a 4x difference as well):
Coverage Reporting
#58850
npm tests -- --no-lint --coverage
.Knip
#56817
/** @knipignore */
tag to the preceding comment.@internal
Tagging--stripInternal
is supposed to do, and say it only applies to JSDoc comments.// Do not add an @internal tag to the next declaration
, since TypeScript will now consider that unrelated.--stripInternal
, we've always said "it has bugs, ehhh, arguable behavior."More "Primitive" Operations in Core Utilities
#58873
some
function was just a big hot path.||
checks for truthiness, but??
only checks fornull
/undefined
.undefined
are faster than truthiness.for
-of
loops create iterators butfor (let i = 0; i < arr.length; i++)
doesn't.core.ts
to avoid too much noise.The text was updated successfully, but these errors were encountered: