On this page
Check providers: the TOML-less way to add checks, where a provider returns a list of fully-formed check specs (metadata plus a ceiling-typed impl).
#typescript/src/checks/provider
#typescript/src/checks/provider
Check providers: the TOML-less way to add checks, where a provider returns a list of fully-formed check specs (metadata plus a ceiling-typed impl). Providers run lazily at the first registry read (materialization), memoized per cwd, and their specs go through the same single add-path as TOML-declared checks.
Three check-system hooks (do not confuse them):
1. Check provider (app.registerCheckProvider) -- REGISTRY POPULATION: decides WHICH checks exist. Registering a provider ENABLES the check system (a TOML-less app with a provider gets a working check command). 2. Check-context factory (app.setCheckContext) -- PROJECT CONSTRUCTION: called once per run with no arguments to build the CheckContext handed to every check impl. Decides WHAT project the checks see. 3. Scope adapter -- Python-only per-check context projection. TS matches Go: no scope adapter, the scope field is parse-only.
Parity sources: go/strictcli/check_provider.go with Python register_check_provider / _materialize_check_providers (~3238-3342) as the divergence ground truth for the runtime guards.
#CheckSpec
export class CheckSpecA fully-formed, ceiling-typed check produced by a check provider. Opaque by construction: obtain one only from the errorCheckSpec / warnCheckSpec builders. Providers return arrays of these.
#ErrorCheckSpecInit
export interface ErrorCheckSpecInit extends CheckSpecInitBaseInitialization options for an error-severity check spec. The impl receives an ErrorReporter.
#WarnCheckSpecInit
export interface WarnCheckSpecInit extends CheckSpecInitBaseInitialization options for a warn-severity check spec. The impl receives a WarnReporter.
#errorCheckSpec
export function errorCheckSpec(init: ErrorCheckSpecInit): CheckSpecBuilds an error-severity check spec for a provider. The impl receives an ErrorReporter (which can mint both error- and warn-severity problems).
#warnCheckSpec
export function warnCheckSpec(init: WarnCheckSpecInit): CheckSpecBuilds a warn-severity check spec for a provider. The impl receives a WarnReporter, which structurally lacks error-minting: a warn check cannot cascade.
#materializeCheckProviders
export function materializeCheckProviders(state: ChecksState): voidRuns all registered providers and inserts their specs into the registry, memoized on the cwd at materialization time. Single chokepoint called at the start of every registry read (the check command handler and the programmatic app.runChecks). A repeat call in the same cwd is a cheap no-op; a cwd change re-runs the providers (dropping the previous provider-sourced defs first). A throwing provider is a hard error in every mode; a provider returning undefined or an empty list is honest-empty.
Reentrancy: a provider must not trigger check execution during materialization (behavior is undefined -- unbounded recursion). A provider's job is to return specs, nothing else.
#resetCheckProviderCache
export function resetCheckProviderCache(state: ChecksState): voidDrops every provider-sourced definition and clears the materialization memo so the next registry read re-runs all providers. Backs app.resetCheckProviderCache; does NOT unregister the providers themselves.