JavaScript and TypeScript — one bar for every author

Junior, senior, or AI: same repo, different habits.
Lintora checks every change against the policies you turned on and keeps quality consistent.

Within that coverage, it nudges code toward senior practice. It does not merge for you — you fix, waive, or ignore on purpose.

Shared rules cut spaghetti early, make onboarding lighter, and trim repeat bugs so new work spends less time on old debt.

  • Policies encode what "good" means here; every diff is checked the same way.
  • Humans and agents read the same signals instead of guessing tribal lore.
  • Strictness is yours: enable families, tune paths, own waivers.

What that tends to mean:

  • Fewer "we fixed this twice" regressions on human and AI patches.
  • Risky shortcuts surface before they spread across the tree.
  • New engineers and agents onboard against written rules, not archaeology.

Fewer repeat incidents

Known failure classes stop sneaking back in on the next human or AI diff.

Onboarding that reads the repo

New hires and agents learn the real rules from output, not from chasing tenured engineers.

Cheaper features over time

Less silent debt means less rework — more calendar for what you planned to build.

Overview, examples, and common questions

Junior, senior, or AI: same repo, different habits.
Lintora checks every change against the policies you turned on and keeps quality consistent.

Before and after — login credentials in the URL versus POST body

Before — secrets in the query string (GET)

async function login(user, pass) {
  const res = await fetch(`/login?user=${user}&pass=${pass}`);
  return res.json();
}

After — POST JSON body, typed parameters, explicit HTTP errors

async function login(user: string, pass: string) {
  const res = await fetch(`/login`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ user, pass }),
  });

  if (!res.ok) {
    throw new Error(`login_failed:${res.status}`);
  }

  return res.json();
}

Token exposure guard

WHAT LINTORA REPORTS (MESSAGE)

ACTION REQUIRED: Remove token from logs or URL parameters. Sensitive credential exposure detected.

WHY IT MATTERS (ROOT CAUSE)

Identification and Authentication Failures (OWASP A07). Authentication tokens exposed in plain text within logs or URLs can be intercepted by unauthorized parties, leading to session hijacking and full account compromise. URLs are logged by various systems (proxies, browser history), and log files are frequent targets for internal reconnaissance.

WHAT TO DO (FIX)

1. IMMEDIATELY remove tokens from log messages and URL strings. 2. USE the 'Authorization' header (e.g., Bearer <token>) for all API requests. 3. LOG only non-sensitive metadata such as userId or correlationId. 4. REDACT or MASK the token if it must be logged for critical troubleshooting. 5. IF exposure is manually verified as safe or masked, use the explicit exception: // lintora-disable-next-line SEC-001-027.

AI writes code.

Lintora enforces standards.

Make AI-generated code production-grade.

Lintora Overview

Lintora is a policy enforcement tool for codebases that ensures consistent quality across human and AI-generated code. It runs a versioned catalog of named policies on JavaScript and TypeScript, reports structured findings with stable IDs, and supports the same workflow locally and in CI.

Key Features

  • Policy-based code validation
  • AI-aware rule enforcement
  • CI/CD integration
  • PR-level feedback

Use Cases

  • Teams using AI coding tools
  • Scaling engineering teams
  • Enforcing internal standards
  • Governing JavaScript and TypeScript before merge

Use case: AI-assisted feature ships an unsafe default

A model-generated pull request adds a new API client with permissive TLS, silent error swallowing, and credentials read from query strings. ESLint stays green because the file is formatted and imports resolve. Lintora flags the security and validation policies you enabled, cites each hit with a stable policy ID, and blocks merge until the team fixes or explicitly waives the rule. The same bar applies whether the author is a human or an agent.

Pull request review example

Thread mirrors the policy spotlight above: same catalog-style message, root cause, and fix text Lintora emits for that rule.

  • Lintora SEC-001-027 (CRITICAL): Sensitive credential pattern in URL — align with token exposure guard.
  • Why it matters: query strings show up in browser history, reverse proxies, and analytics.
  • Author: Switched login to POST + JSON body and added `res.ok` handling so secrets are not carried on the URL.

Common questions

What is Lintora?

Lintora is a static analysis and governance-as-code engine for JavaScript and TypeScript. It runs a curated catalog of named policies, each with a stable ID, on every change so human, junior, and AI-generated diffs face the same merge bar. It reports structured findings; it does not silently auto-merge or blanket auto-fix production logic in CI.

How is it different from ESLint / SonarQube?

ESLint excels at style and plugin rules you configure yourself; SonarQube often powers hosted dashboards and multi-language programs. Lintora focuses on semantic engineering policies for JS and TS, ships rules inside the dependency you pin, runs locally and in CI with deterministic output, and pairs cleanly with ESLint for layout while acting as a fast in-repo policy gate where SonarQube is heavier or broader than you need.

Does it work with AI-generated code?

Yes. Lintora treats the diff as the source of truth: every pull request is checked against the same enabled policies regardless of author. High-volume AI edits get the same stable IDs, severities, and waiver mechanics as human-written code, so risky patterns surface before merge.

How does policy enforcement work?

You enable policy families and paths for the repository, pin @lintora/core, and run npx lintora run locally and in CI. Each policy maps to AST-first runners (with type-aware hooks where needed), emits findings with stable IDs you can gate on, and supports intentional waivers per rule instead of silent blanket disables.

More authors, more speed — the bar slips first.

AI and juniors ship volume; seniors disagree on details. Without a shared check, quality becomes whoever touched the file last.

  • Output varies by author and by model run — style, errors, and risk do not self-align.
  • Tribal rules live in chat until something breaks; then you pay in nights and weekends.
  • Lintora reports named policy hits you enabled — not a vague "make it cleaner" thread.
  • One policy set for the repo: IDs stay stable so humans and tools argue about the same finding.
  • Waivers name a rule when you accept the trade — not silent blanket disables.
  • Debt stacks quietly until merges feel like bets.

If "done" is not defined in the repo, every merge is a lottery.

Lintora catches drift on the diff while it is still cheap to fix.

For developers

You stay in charge. Lintora only surfaces where the code diverges from policies you agreed to run.

Each finding is:

  • Tied to a policy ID you can read and discuss
  • About real failure patterns, not formatting taste
  • Yours to fix, waive with intent, or narrow scope — merge stays your call

Install @lintora/core from npm, run npx lintora run at the repo root, mirror the same command in CI. Flags and config: README on the npm package page and this site's CLI guide.

Formatting is one job. Policy checks are another.

Formatters keep layout consistent. Lintora runs policies — security, APIs, async, architecture — so every author sees the same risks described the same way.

Layout and style

Speed without a written bar — each author picks their own threshold.

Policies you enable

The bar lives in policy text: every change is checked against rules you turned on.

Layout and style

Suppressions spread until no one knows what still applies.

Policies you enable

You waive one rule on purpose, or you change the policy.

Keep your formatter for layout. Use Lintora where the team agrees the rule is non-negotiable.

Install from npm

Why Lintora

Stop letting quality depend on who — or what — wrote the last change.

The problem

  • Authors and models disagree on the bar unless it is written down and run.
  • "Senior quality" in Slack does not block a bad merge.
  • Problems stay invisible until production pain or endless cleanup sprints.

Lintora

  • Policies say what good means for this repo; Lintora runs them on every change.
  • Humans and AI hit the same gate before merge.
  • You choose per finding: fix, waive with reason, or change what is enforced.

How it is different

  • Engineering policies with stable IDs — not vibes.
  • Built for high-volume edits: a bar beats raw speed alone.
  • Same policy pack locally and in CI — no mystery remote rule feed.

In practice

  1. Pin @lintora/core and enable the policy families that match your risk.
  2. Run the same CLI locally and in CI; read the same findings everywhere.
  3. Decide per hit: fix, waive one rule with intent, or tighten policy.
  4. Gate merges on paths and severities your team owns.

Policy counts on this page come from the same registry the engine ships.

Full CLI and configuration: @lintora/core on npm.

How it runs

Static analysis for JavaScript and TypeScript: AST-first runners, optional type-aware hooks. Policy logic ships in the package you pin — not from a hosted rule sandbox.

Coverage highlights

  • Security, APIs, async and concurrency, architecture
  • React and React Native performance, logging discipline
  • Type safety and null handling, testing integrity
  • Structured findings you can route to owners or CI gates

Runs where your code lives

  • Monorepo-friendly include and exclude paths
  • Deterministic runs for comparable CI output
  • Machine-readable reports you can diff between commits

See what breaks your bar

Run Lintora on the repo. Output lists every enabled policy break — fix on your terms, then wire the same command in CI.

Open npm install steps

Scope

At a glance

  • Static analysis for JavaScript and TypeScript before production.
  • A broad policy catalog: humans and AI answer to the same IDs.
  • Rules ship in the dependency version you pin — predictable upgrades.

What Lintora is

Governance-as-code for JS/TS: many policies, each with a focused runner and optional type hooks.

  • Findings you can route, diff, and gate on — not prose in a wiki.
  • One command locally and in CI.

What ships in the package is what your team validated.

What Lintora is not

Boundaries keep expectations honest.

  • Not a replacement for the TypeScript compiler for whole-program proof.
  • Not multi-language today: JavaScript and TypeScript via ESTree.
  • Not a silent auto-fixer in CI by default: it reports first; you choose fixes.
  • Not a runtime monitor — it inspects source before deploy.

Pair Lintora with strict TypeScript, tests, and review for full assurance.

Policies by category

306 policies across 22 categories.