Skip to content
HomePagesHomePages template kit
Menu
Start here
What you're buildingInstallFirst renderRead the starterAdd a slotShip it
Concepts
The pipelineSections and declarationsSlotsFacts and provenanceAI fillFixtures and scenariosValues and emptinessThe marker contractServer and clientTheme modelFrames and formatsComposition and reconcileVersioningStaying current
Guides
API reference
Rules

template-kit check

The `template-kit check` command — its arguments, flags, exit codes and constraints.

Typecheck, lint, and validate a template.

Synopsis

Section titled “Synopsis”
Terminal window
template-kit check [template] [--all] [--json] [--provenance] [--no-auto-update]

Arguments

Section titled “Arguments”
Argument Required What it does
template no Check one template by its key. Omitted, the template is inferred from the current directory, or is the workspace’s only one.

Flags

Section titled “Flags”
Flag Type Default What it does
--all boolean false Check every template in the workspace
--json boolean false Print one machine-readable report instead of human output
--provenance boolean false Also report how each slot of each fixture resolved. Informational — it can never fail a run
--no-auto-update boolean false Skip the package refresh this command runs first when the workspace is behind the published release

Exit codes

Section titled “Exit codes”
Code When
0 every selected template and the workspace pass every stage and gate that could be measured
1 any stage or gate reports a finding, or the run cannot proceed at all

Constraints

Section titled “Constraints”
  • A workspace holding more than one template must name one or pass --all.
  • A run that selects zero templates is a failure, never a silent pass — an empty selection gates nothing.
  • Resolves TypeScript, ESLint and esbuild from the workspace, not from this package: the compiler that judges your types is the one you pinned.
  • Every threshold below is a platform acceptance criterion, not a preference. No flag or config file raises one.

Stages

Section titled “Stages”

Run in order, once per selected template. None of them aborts the run — a template with several unrelated problems reports all of them in one pass, not one class of fix at a time.

  1. typecheck — The workspace’s own TypeScript compiles the template’s files, judged against the workspace’s own tsconfig.json.
  2. lint — The workspace’s own ESLint runs its eslint.config.mjs — and so the authoring preset it imports — over the template’s files.
  3. validate — The schema, fill-spec, fixture and template contracts: every cross-reference between a section’s contract files, and a template’s template.ts against the sections it composes.
  4. tree — The rules a one-file-at-a-time linter cannot express: a missing contract file, a slot declared in the schema with no marker anywhere in the section’s JSX, a hand-written CSS file’s own rules.
  5. render — A determinism probe (every fixture rendered twice, byte-identical) and a scan of the rendered HTML for objective defects — a stray [object Object], a bare null/undefined/NaN leaf, a src-less <img> — plus, for the typical fixture, that the editor’s sidebar order matches the page’s real render order.
  6. size — Every section’s renderer bundle, compiled stylesheet and island bundles, gzipped, against a fixed byte budget; and its static assets, budgeted raw since they are already compressed. Weighs every run, whether or not anything is over: the report prints the per-section table either way, and the renderer and island budgets report a first tier long before they refuse a second.

Dependency gates

Section titled “Dependency gates”

Evaluated once per invocation regardless of --all: they are properties of the workspace’s one package.json, lockfile and installed tree, never of a template. Their findings land under workspace in the report.

Rule What it requires
template-kit/lockfile-missing The workspace has a package-lock.json — the precondition for every gate below.
template-kit/lockfile-stale That lockfile satisfies package.json — nothing is missing or invalid.
template-kit/single-react Exactly one copy of React is installed anywhere in the tree.
template-kit/audit-severity No npm audit finding at or above the severity floor below.

Every one of them reads the tree npm ci builds from your package-lock.json, and two of them ask npm itself for the report. When there is nothing to read — no lockfile, or an npm that returns no parseable report — the run says so rather than guessing: those gates are reported as not measured rather than as violations, which is a warning line in the human report, its own field beside the findings under --json, and no effect on the exit code.

Not measured is not a pass. Nothing about your dependencies has been cleared at that point, and a submission is accepted only on a run that measured every gate. Fix what stopped the measurement — commit a lockfile (which template-kit pack requires of a submission anyway), or make npm runnable — and check again.

Thresholds

Section titled “Thresholds”

Fixed platform acceptance criteria. No flag, config file or workspace setting raises one.

Budget Limit
A section’s renderer bundle, gzipped, React excluded — reported above 50 KB
A section’s renderer bundle, gzipped, React excluded — refused above 300 KB
A section’s stylesheet, gzipped, including CSS pulled in from packages — refused above 50 KB
One island (browser) bundle, gzipped, React excluded — reported above 50 KB
One island (browser) bundle, gzipped, React excluded — refused above 600 KB
One hand-placed static asset (svg/font/url()-referenced image), raw — they are already compressed — reported above, never refused 150 KB
Every island in the template, gzipped and summed — reported above, never refused 1024 KB

A vulnerability at or above high or critical severity fails the run.

See also

Section titled “See also”
  • Every command — the rest of the CLI’s surface.
  • This CLI drives any kit in ^9.0.0; template-kit --version prints the pair.