strictcli v0.39.0 /typescript/src/checks/runner
Updated
On this page

Check runner: filtering (tag DSL + name glob), DAG-ordered execution with dependency pull-in, cycle detection, and dependency-failure cascade-skips.

#typescript/src/checks/runner

#typescript/src/checks/runner

Check runner: filtering (tag DSL + name glob), DAG-ordered execution with dependency pull-in, cycle detection, and dependency-failure cascade-skips. It also handles the purity partition and integer-millisecond wall-clock timing.

Parity sources: go/strictcli/check_runner.go with Python _filter_checks / _resolve_check_order / _find_cycle / _run_checks (~6841-7085) as the divergence ground truth (FIFO Kahn queue, DFS cycle path, fnmatch globs).

#globToRegExp

TS typescript
export function globToRegExp(pattern: string): RegExp

Translates an fnmatch-style glob (*, ?, [seq], [!seq]) into an anchored RegExp, mirroring Python fnmatch.translate: an unterminated "[" is a literal, "]" directly after "[" or "[!" is a literal member, and there are no error cases (Python globs never fail to compile).

#filterChecks

TS typescript
export function filterChecks(

Selects checks based on tag expression, name glob, or runAll. When both tagExpr and nameGlob are provided, the result is their intersection. Neither filter selects nothing.

#resolveCheckOrder

TS typescript
export function resolveCheckOrder(

Resolves execution order via topological sort (Kahn's algorithm with a sorted seed and FIFO queue -- Python parity), pulling unselected dependencies into the execution set. Throws on cycles with a formatted cycle path.

#checkIsPure

TS typescript
export function checkIsPure(def: CheckDef): boolean

Whether a check is executable under the purity partition: declared pure AND not requiring network access. Everything else is "impure".

#RunChecksOutput

TS typescript
export interface RunChecksOutput

#runOrderedChecks

TS typescript
export async function runOrderedChecks(

Executes checks in order, cascade-skipping dependents of gated (FAIL) checks. Cascade keys ONLY on a derived FAIL (an error-severity problem present) or a prior cascade-skip: a WARN outcome satisfies the dependency (dependents still run) and only affects the exit code -- warn-severity checks physically cannot cascade because WarnReporter lacks error-minting. An explicit SKIP from an impl is NOT a failure -- dependents still run.

Purity partition (pureOnly): only pure, non-network checks execute; every other selected check is listed (not run, no exit-code contribution). A check also joins the listing when any dependency was listed -- an unexecuted dependency means its precondition cannot be verified. The failed-dependency cascade takes precedence over the listing.

Search