gimme-the-lint
Summary
Most projects use linters to catch mistakes and keep code clean. The problem is
that when you add a linter to a project that already has a lot of code, the
linter finds hundreds — sometimes thousands — of old problems. Turning linting
on would block every commit until someone fixes all of it, so teams just never
do it. gimme-the-lint solves this by remembering the old problems and only
blocking your work when you create a new one. Your team cleans up the old
stuff at its own pace; meanwhile no new mess gets in.
v2.0 generalizes that idea to any linter and any language. It is no longer
"ESLint + Ruff for webapps" — it is a progressive-lint engine with a
pluggable linter adapter for each tool, across JavaScript/TypeScript, Python,
Go, Rust, Terraform, and Ansible, in any monorepo shape.
How it works
gimme-the-lint creates baselines — snapshots of every existing violation,
stored per app under .gtl/. On each run it lints, then asks one question of
every violation: is this new, or was it already baselined? Only new violations
block.
The trick is the fingerprint. Each violation is identified by
file + rule + message — deliberately not by line number. So a baselined
violation survives code moving up or down a file; only a genuinely new problem
is ever flagged. (In v1 this job was outsourced to the third-party
lint-to-the-future; v2 owns it, which is what makes every linter equal.)
Each app is bound to the linters its package manifest implies — package.json
→ ESLint, pyproject.toml → Ruff, go.mod → golangci-lint, Cargo.toml →
Clippy, biome.json → Biome, ansible.cfg / galaxy.yml → ansible-lint.
Terraform has no manifest, so a directory of *.tf / *.tofu files binds to
tflint by extension. Drift detection runs per app, so a config or linter-version
change in one app never churns the baselines of another.
Features
- Progressive linting — only new violations block; existing ones are baselined
- In-house diff engine — line/column-independent fingerprints survive code shifts
- Pluggable linter adapters — the choice of linter is config, not a hardcode
- Polyglot — JavaScript/TypeScript, Python, Go, Rust, Terraform, Ansible out of the box
- Per-app model — auto-discovers every package in a monorepo; no
frontend/
- Per-app drift detection — app add/remove, config change, linter version, age
- Best-practice configs shipped —
install seeds each app with a curated,
security-aware config for its linter (create-if-absent — never clobbers yours)
- Security linting built in — gitleaks for secrets across every codebase,
plus per-language security rules (gosec, Ruff
S, eslint-plugin-security)
- Idempotent skips — an app with code but no installed linter is warn-skipped
(never blocks) — or fails loudly under
--strict
- Offline install — air-gapped mode for regulated environments
- Greenfield mode — "strict from day one" with empty baselines
- Git hooks, CLI, GitHub Action, Claude Code plugin — one engine, four front doors
- LLM-optimized output — failures tell Claude Code to auto-fix without asking
Supported linters
| Language | Linter | Bound by |
|---|
| JavaScript / TypeScript | eslint | package.json |
| JavaScript / TypeScript | biome | biome.json (supersedes ESLint) |
| Python | ruff | pyproject.toml, requirements.txt, setup.py |
| Go | golangci-lint | go.mod |
| Rust | clippy (cargo clippy) | Cargo.toml |
| Terraform / OpenTofu | tflint | *.tf / *.tofu files (no manifest) |
| Ansible | ansible-lint | ansible.cfg, galaxy.yml |
Shipped lint configs
install seeds every discovered app with a best-practice ("recommended" tier)
config for its linter — created only if absent, so your own config is never
overwritten. Each ships a sensible default rule set and a single lever to
dial strictness up or down:
