alint vs other repo-level linters
alint is the active-maintenance, language-agnostic, fast, structurally-aware slot in the repo-linting ecosystem. It is not trying to replace ESLint, Clippy, ruff, or your favourite per-language linter. Those operate on code; alint operates on filesystem shape and file content.
Routing table: start here
If you're shopping because…
| You want… | Look at… |
|---|---|
| A Repolinter replacement (archived early 2026) | alint; the rest of this page explains why |
| Filename + directory conventions only | ls-lint: narrower scope, even smaller binary |
| One tool that orchestrates 70+ language linters in containers | Megalinter: different shape (orchestrator, not linter) |
| Indent / line-endings / charset enforced in the editor | EditorConfig. alint
consumes .editorconfig via its
tooling/editorconfig bundled ruleset; both can
coexist
|
To keep your hack/verify-*.sh directory | Stay where you are, but read the kubernetes case study to see what 17 of those 50 scripts could become declaratively |
Feature matrix
| alint | Repolinter | ls-lint | Megalinter | EditorConfig | Custom shell | |
|---|---|---|---|---|---|---|
| Maintenance status | active (v0.9.x; 2026-05) | archived 2026-02 | active | active | universal standard | as much as you maintain |
| Scope | filesystem shape, file content, cross-file relations | OSS-baseline files | filenames + dir layout | orchestrates ~70 native linters | text-format conventions | whatever you write |
| Languages | language-agnostic | language-agnostic | language-agnostic | one container per language | text-format only | whatever you write |
| Install footprint | one static Rust binary (~10 MB) | Node.js + npm install | one Go binary (~5 MB) | Docker (heavy) | editor-native (zero install) | bash + greps |
| Rule count | 60 rule kinds | ~30 rules | ~5 (filename/dir) | (N/A, orchestrator) | 7 properties | unbounded |
| Bundled per-ecosystem rulesets | 19 (rust, node, python, go, java, monorepo, CI, hygiene, agent, compliance) | none | none | per-language container sets | none | none |
| Cross-file rules | yes (pair, for_each_dir, dir_contains, unique_by, every_matching_has, …) | no | no | (per-tool) | no | hand-rolled |
| Structured-query rules over JSON/YAML/TOML | yes (RFC 9535 JSONPath) | partial (jsonpath-plus) | no | (per-tool) | no | hand-rolled |
Conditional when: gates | yes (bounded expression language) | no | no | (per-tool config) | no | hand-rolled |
| Composition | yes (extends: local + HTTPS+SRI + alint://bundled/…) | partial (axiom inheritance) | no | (per-tool config) | no | source/include |
| Auto-fix | 12 file ops | partial (file presence) | no | (per-tool) | (editor-side) | hand-rolled |
| Output formats | 8 (human, json, sarif, github, markdown, junit, gitlab, agent) | json, markdown | text | (varies) | (N/A) | however you echo |
| Agent-aware output | yes (per-violation agent_instruction) | no | no | no | (N/A) | hand-rolled |
| Performance | sub-second on 100K files; ~12 s on 1M files | not benchmarked | fast (Go + minimal scope) | slow (container per linter) | editor-instant | varies |
| Public benchmark history | per-release | none | none | none | (N/A) | none |
| Production case studies | 30 OSS repos | (community list, unmaintained) | (homepage examples) | (homepage examples) | universal | (yours) |
When alint is the right tool
- Your repo has structural conventions enforced nowhere. See tokio and uv.
- Your repo is polyglot and no per-language linter sees the cross-language conventions. arrow has 6 languages, 21 lint hooks across 14 tool repos, and 0 tools that see cross-language shape.
- You want structured output for AI agents that suggests both the fix and the rule context. The
agentoutput format ships per-violationagent_instructionstrings. - You want one fast static binary instead of a Node/JVM/Python/Docker runtime in your CI pipeline.
When alint is NOT the right tool
- AST-aware linting: use ESLint, Clippy, ruff, etc. alint deliberately operates on bytes/structure, not parsed code.
- SAST (security-focused code analysis): use Semgrep, CodeQL.
- IaC scanning: use Checkov, Conftest, tfsec.
- Secret scanning: use gitleaks, trufflehog.
- Filename conventions only: ls-lint is smaller and more focused.
- Text-format conventions only: EditorConfig lives in the editor, no CI step needed.
Per-tool deep dives
vs Repolinter
Repolinter was
the TODO Group's tool for OSS-baseline checks. It was
archived in February 2026. alint covers Repolinter's rule
catalogue as a strict superset: the bundled
oss-baseline@v1 ruleset (15 rules) maps Repolinter's
file-presence + content-shape axioms; the rest of alint's catalogue
(60 rule kinds total, 19 bundled rulesets) is net-additional.
What you gain: active maintenance, cross-file rules, structured-query rules with full JSONPath, bundled per-ecosystem rulesets, auto-fix, sub-second performance on 100K-file workspaces, agent-aware output. What you lose: nothing material.
vs ls-lint
ls-lint is a Go binary that
enforces filesystem naming conventions and is faster at its
specific job. Use ls-lint if filename conventions are the only
thing you care about. Use alint if filename conventions are one of
many things. alint's filename_case and
filename_regex rules cover the same ground, plus content
checks, structured queries, cross-file rules. There's no need to run
both.
vs Megalinter
Megalinter is a Docker-based
orchestrator wrapping ~70 native linters in
containers. Different shape entirely. The two coexist cleanly:
Megalinter orchestrates the language-specific lint stack; alint runs
as one additional check inside Megalinter for structural coverage.
See pytorch: they built
lintrunner for the same orchestration role and ~86% of
its 57 adapters are structural; alint sits beneath as the structural
floor.
vs EditorConfig
EditorConfig is the universal
standard for text-format conventions. It lives in your editor; no
CLI. alint consumes .editorconfig via
the bundled tooling/editorconfig ruleset, which enforces
the same conventions at PR time as a backstop. Use both:
EditorConfig keeps the developer's editor honest in real time; alint
keeps CI honest at merge time.
vs custom shell scripts
If your repo has a hack/verify-*.sh directory, you've
built the right thing for what existed when you started. The
maintenance burden tends to grow over time, though, and the patterns
are usually structural. alint replaces the structural subset:
kubernetes converted 17 of
50 verify scripts; cpython
consolidated 12 of 56 validation surfaces;
pytorch's lintrunner shows
the same pattern at the orchestration layer. The realistic outcome
isn't 100% replacement; it's consolidation of the declarative
subset.
Migrating from another tool? Step-by-step guides: Repolinter · ls-lint · custom bash scripts.