template-kit/parse-error

A file so broken it never became an AST. Every other rule needs one; this is what’s reported when there isn’t one to have an opinion about.

Rule

Every other lint rule runs against a parsed file — an AST it can walk and ask questions of. When a .ts/.tsx file cannot even be parsed (invalid syntax: an unclosed brace, a stray token, a JSX tag that never closes), there is no AST for any rule to run against, and no rule id of its own to report. This id is what’s reported in that one case instead: the parser’s own message, relocated to the file and line it names.

This is the only diagnostic under this id — it is not a rule you can violate by writing working code a particular way, the way no-hex or no-inline-style are. It exists so that “the file didn’t parse” is a rule-id and a fix hint, not silence or a raw crash.

Reason

A stage never aborts the run — an author fixing one file’s problem must see every other file’s problems in the same run, not discover them one release at a time. A parser exception is the one case where that promise is hardest to keep: there is genuinely nothing else to check about a file that doesn’t parse. Reporting it under its own id, rather than dropping it or letting it throw, keeps that promise intact.

You may see the same file flagged here and under typecheck: the lint stage and the typecheck stage each parse the workspace independently, and a syntax error fails both parsers, so both stages report it, each in their own words. Fixing the syntax error clears both.

Fix

Read the message — it is the parser’s own error, naming the file and the line. Fix the syntax at that location.

Before

sections/hero/Renderer.tsx

export function Renderer() {
  return (
    <Section>
      <h1>{headline}</h1>
    </Section
  );
}

sections/hero/Renderer.tsx:6
  Parsing error: '>' expected.

After

sections/hero/Renderer.tsx

export function Renderer() {
  return (
    <Section>
      <h1>{headline}</h1>
    </Section>
  );
}

See also

• typecheck — the sibling failure one layer up: a file that parses but does not type-check.