Skip to content
onsystemv0.6.0

Rule

no-unknown-component

error by default

Components must exist in the design system: no invented components or dot-notation members.

What it catches
Invented components, dot-notation members that do not exist (<Card.Header>), typos. A name from a module the model left out (an excluded folder, a barrel that re-exports one) is not called invented: check says once which components it could not check
Why it matters
Agents mix up conventions between libraries: <Card.Header> where the system exports flat parts, or a component that only exists in another kit. TypeScript reports it once the file compiles in the project; check_ui reports it in a snippet the agent has not saved yet, and names the part to use.

Example

What check_ui returned for this code against the demo design system when the site was built, from version 0.6.0.

What the agent wrote
<Card>  <Card.Header>    <Card.Title>Billing</Card.Title>  </Card.Header></Card>
After the fixthe rule’s own fixes
<Card>  <CardHeader>    <CardTitle>Billing</CardTitle>  </CardHeader></Card>
check_ui
  1. error2:4fix included

    <Card.Header> does not exist: Card is composed from flat parts. Use <CardHeader> (import { CardHeader } from "@/components/ui/card").

  2. error3:6fix included

    <Card.Title> does not exist: Card is composed from flat parts. Use <CardTitle> (import { CardTitle } from "@/components/ui/card").

How the fix is chosen

The flat part (<CardHeader>) or closest name, auto-fixed only when that component is imported.

Every finding in the example carries its fix as text edits, which the agent applies, and so does eslint --fix. The code after the fix is those edits, applied.

Options

Its default severity is "error". Set it to "off", "warn" or "error" in onsystem.config.json, or as onsystem/no-unknown-component in the ESLint plugin.

onsystem.config.json
{  "rules": {    "no-unknown-component": "warn"  }}

The config file covers the rest, including overrides for folders.

Suppressing a finding

When a finding is intended, a comment turns the rule off for the next line and says why after --. Checked when the site was built: the comment hides the finding on the line below it, and the others stay.

With the comment
<Card>  {/* onsystem-disable-next-line no-unknown-component -- why this one is intended */}  <Card.Header>    <Card.Title>Billing</Card.Title>  </Card.Header></Card>

onsystem-disable-next-line covers the next line, onsystem-disable-line its own, and /* onsystem-disable */ the rest of the file (at the top, the whole file). Without rule names they turn every rule off. A misspelled rule name is reported as a suppression warning, with the closest one, and suppresses nothing; syntax errors cannot be suppressed. For whole folders or kinds of files, such as legacy screens or generated code, use overrides in the config.