How the Evanion libraries are tested

This section reports the tests behind the published @evanion/* libraries. The build that published this site ran those tests and wrote every figure in it. The Measured at line under this paragraph names the commit that run tested.

Measured at 86c6966e (2026-11-06) on Node v24.20.0, by the build that produced this page.

What the testing section covers

The testing section has three pages, and each renders its figures from the test run of the build that published this site:

• This page counts the tests in each library and shows how to rerun them.
• The acl security register covers @evanion/acl, the library that decides whether a user may take an action on a record. Its security register, libs/acl/SECURITY.md, lists the classes of attack the library is tested against, and the page shows each beside its test.
• What coverage measures gives each library’s coverage percentages, and names the files whose branches no test took.

The documentation’s examples run as tests

A TypeScript example on a package page is copied from a named region of a package’s docs/examples.md, a test file, or a demo application under apps/: the span of the file between a #region name marker and its #endregion.

Four mechanisms hold an example to its test:

• A code block in a package’s README or docs/examples.md whose fence opens with ts @import.meta.vitest runs as a test in that package’s vitest run.
• A // -> value comment on a line of such a block becomes an assertion that the line returns value.
• The page and the test read the same named region, so the example on the page is the code the test ran.
• An example rendered with Twoslash, which shows the compiler’s types on hover, is compiled against the package’s built dist/. An example that shows a compiler error on purpose fails the build if the error goes away.

The block below is an @evanion/acl example, set in Baize, the board game shop every acl example uses: a customer who asked a question may edit it.

import { policy } from '@evanion/acl';
 
type Question = { id: string; askedBy: string };
 
const access = policy<{ id: string }, { question: Question }>()
  .for('question', (p) =>
    p.allow('update', p.eq('object.askedBy', 'subject.id')),
  )
  .build();
 
const decision = access.can({ id: 'customer-41' }, 'question', 'update', {
  id: 'q7',
  askedBy: 'customer-41',
});
decision.allowed; // -> true

policy() writes the rules. p.allow grants the update action when its condition holds, and p.eq compares the question’s askedBy field with the user’s id. The fence in libs/acl/docs/examples.md that holds this code carries the @import.meta.vitest marker on its opening line, which the page does not render. The package’s vitest run executes the block, and the // -> true line is the assertion.

An example that runs nothing, such as a type signature, carries a tag such as signature or no-run in its fence. A guard, a test in tools/repo-checks that fails the build when a page breaks a documentation rule, fails when a section of this site, such as /acl, gains a hand-written example with no such tag.

The tests in each library

The table counts the test cases and test files each @evanion/* library’s vitest run collected, beside the command that reruns it.

The table covers every library under libs/, and a new library appears in it on its first release. @evanion/acl holds more cases than any other library. Its adversarial suite, the tests in libs/acl/src/security that each attempt an attack, is what the security register page renders. A count says how many tests ran and nothing about what they assert, which is why the register shows the cases themselves.

The Kinds column names the kinds of test found in each library’s run, read off the path of each file that ran:

Four more kinds of test run outside any library’s vitest configuration, so the table counts none of them:

• expectation comments — a rewrite inside the doctest pipeline, with no test file of its own, in tools/doc-examples/src/expect-comments.ts. No count on this page.
• repository checks — tools/repo-checks, which is not a published library, in tools/repo-checks/vitest.config.ts. No count on this page.
• build-output assertions — a demo app, which reads what its own build emitted, in apps/storefront/src/build.test.ts. No count on this page.
• packaging verification — its own CI job, belonging to no Nx project, in scripts/verify-packaging.mjs. No count on this page.

Run the tests yourself

Every count on this page reruns from a clone of the Evanion/libraries repository. You need Git and Node 24, the version the repository’s .nvmrc pins.

git clone https://github.com/Evanion/libraries.git
cd libraries
npm ci

To reproduce the exact figures, check out the commit the Measured at line at the top of this page names:

git checkout <commit>

Run one library’s tests, which also writes its coverage report to the library’s test-output/vitest/coverage folder:

npx nx test @evanion/acl

vitest ends on a summary of the tests that passed, and at that commit the count matches the library’s Test cases column above. Replace @evanion/acl with any name in the table’s Package column to rerun another library.

What these tests cannot show

The four limits below apply to every @evanion/* library this section counts.

The guards check that documentation exists

The repository’s guards are tests in tools/repo-checks that fail the build when a page or a README breaks a documentation rule. The export-coverage guard refuses a published export with no example, and says nothing about whether the example is good. The twoslash guard proves a fence compiles, which says nothing about whether the fence shows the right way to use the API.

A guard that tolerates old breaches lists them in an allowance file, a JSON file beside the guard naming each page, section or package the guard tolerates and what each may carry today. One the file does not list may carry none, so the number of tolerated breaches can shrink and cannot grow.

The demo applications are not counted

The demo applications under apps/ run @evanion/acl, and apps/shop-api holds an end-to-end test of a whole request. None of them is in the counts above. So the @evanion/acl row says nothing about whether an application that enforces a policy through it passes.

No third party has audited this code

No outside reviewer has audited these libraries, and the repository publishes no audit report. Most of the code in this repository was written with AI assistance, so each claim in the section points at a test you can run.

The figures describe one commit

The Measured at line names the commit the build measured, and every deploy measures again. If the deploy stopped running the tests, the site would stop updating, and that commit would fall behind the repository’s latest.

The attack cases behind acl

The acl security register covers @evanion/acl. It opens on the helpers and evaluator calls its cases use, then shows each case’s test.