Skip to main content
meow lint analyzes your source for syntax and semantic problems over the same Oxc syntax tree the runtime and formatter use. There’s no second parser to warm up and no ESLint config to assemble. 
meow lint                  # lint the project
meow lint src/             # lint specific paths

​
What it checks

For each file, meow builds the concrete syntax tree and the semantic graph (scopes, bindings, references) and surfaces:
  • Parse errors — malformed syntax, caught with precise spans.
  • Semantic errors — problems that need scope/binding analysis.
  • Starter lints — a baseline set of correctness checks.
Every finding is rendered as a structured diagnostic with the offending line and a caret marker: 
  warning  src/util.ts
  8 │ const value = =;
    │               ^ expected an expression
✗ meow lint
A clean run is quiet and green: 
🐾 meow lint: no diagnostics
meow lint exits non-zero when there are findings, so it gates CI cleanly.

​
Configuring rules

Rule severities live in your one config file, keyed by rule id:
meow.config.json
{
  "lint": {
    "rules": {
      "no-debugger": "error",
      "no-unused-vars": "warn",
      "some-rule": "off"
    }
  }
}
Each value is "error", "warn", or "off". See the configuration reference.
Linting reuses the workspace’s single parse. Running meow lint, meow fmt, and meow check doesn’t parse your code three times — they draw from the same in-memory graph. That’s the parse-once pipeline in practice.

Format next

Reprint your code from the same tree.