alint roadmap

Scope-based; dates are deliberately omitted. Each version is a closed cut: work that does not fit moves to a later version. This page is generated from the canonical engineering roadmap, so it stays in step with the tool.

Where alint stands today

Latest release: v0.16.1. 105 rule kinds across 13 families, 22 bundled ecosystem rulesets, 12 auto-fix ops, and 8 output formats including agent-aware. 30 production OSS case studies under examples/, spanning single-language and polyglot monorepos. Fast at scale: around 1.7 s on a 100K-file workspace bundle, around 18 s at 1M files.

Full release history → · Full benchmarks history → · All 30 case studies →

Version timeline

Every scope-based cut from the first release to v1.0. Status tracks the released version: shipped cuts are what you can install today, planned cuts are what comes next.

Shipped v0.1v0.2v0.3v0.4v0.5v0.6v0.7v0.8v0.9v0.10v0.11v0.12v0.13 13 earlier cuts

v0.14 Security and correctness hardening Shipped

Baseline grandfathering mode plus the post-v0.13 security and correctness audit: two spawn-gate RCE bypasses closed, path confinement made symlink-aware, and the fail-loudly contract tightened across output, CLI, and baseline handling.
v0.15 Rule legibility + manifest-derived scoping Shipped

alint explain surfaces a rule's full detail with a docs link and a one-line summary, rules show and list --search browse the catalog offline, and scope_filter gains manifest-derived path scoping so a rule tracks the manifest that declares its members instead of a drifting hand-maintained glob.
v0.16 Config-format coverage + parser hardening Latest release

XML becomes a first-class target across every format-aware rule, and dotenv, Java .properties, INI, and HCL join as new config formats with their own path-query rule families, alongside a new *_path_absent kind family and a multi-round audit that bounds every config parser against crafted-file denial-of-service.
v0.17 Auto-fix Planned

alint learns to fix what it flags through a tiered fix engine that applies safe fixes by default and gates unsafe and suggestion tiers behind explicit flags, rewriting file content in place, setting or removing structured values across JSON, YAML, TOML, and XML with formatting preserved, repairing file permissions and shebangs, and canonicalizing ordering and headers, with every applied edit verified against the rule that requested it and a bounded fixpoint that either converges or reports exactly what it left unresolved.
v1.0 Stability Planned

A committed DSL and plugin ABI, a frozen alint-core public API, and a versioned documentation site.
Future / backlog Shipped on main

A wasm plugin kind on a wasmtime host with a stable WIT interface, a filesystem sandbox, and a signed plugin registry, plus a language-agnostic duplicate-code detector, all unpinned from a numbered release until the engine work is scheduled.

Full roadmap with per-version detail →

Won't do (deliberate non-goals)

alint's scope is the filesystem shape and contents of a repository, not the semantics of the code inside it. The following are explicit non-goals; the "use X instead" pointers exist so a misguided contribution can be redirected before it's written.

Won't do	Use instead
AST-aware code linting (variable names, unused imports, type checks)	ESLint, Clippy, ruff, golangci-lint, mypy. Every language has one.
SAST (security-focused code analysis: tainted-data flow, injection, dangerous APIs)	Semgrep, CodeQL
IaC scanning (Terraform / Kubernetes / Docker security policies)	Checkov, Conftest, tfsec
Secret scanning (find API keys / tokens in tracked files)	gitleaks, trufflehog
Commit-message linting (Conventional Commits etc.)	commitlint, committed
Build-system orchestration (running 70+ language linters in containers)	Megalinter, pre-commit, `lintrunner`, `bazel build //...`
Codegen / generator running ("regenerate the file and assert it matches")	The opt-in `generated_file_fresh` primitive is the explicit exception, but the default non-goal stays: alint does not run your generators by default
Dependency-graph problems (import cycles, unused deps, version conflicts)	`cargo deny`, `bazel mod`, `buildifier`, `knip`, `madge`

If your need is on this list, it's not that alint is incapable. It's that alint is deliberately the wrong shape for that need, and the listed tool is the right shape. See also how alint compares to other repo-level linters.

How decisions get made

Design first, code second. Major work lands as a design doc under docs/design/v<MAJOR>/ before implementation. v0.7, v0.9, and v0.10 all shipped this way.
Demand-driven rule kinds. New rule kinds need ≥3 distinct source repos showing the same need (saturation signal). The candidate catalogue in launch-evidence.md aggregates demand from the 30 OSS case studies; each candidate carries a per-source citation.
Public discussion. GitHub Discussions is the low-friction support + feature-request channel. GitHub Issues is the bug channel. Both feed the candidate table.
No private prioritisation. Every roadmap-affecting decision lands in a public commit (typically to docs/design/ or docs/development/launch-evidence.md) before it's encoded in a release. There is no off-list backlog.

When does X ship?

We do not put dates on the roadmap. Two reasons: slipping a public date is worse than not having one (users plan around dates; missed dates erode trust), and scope-based cuts ship better software (filling-time-to-meet-a-date is how feature creep enters). Watch GitHub Releases for the actual ship signal. Every release ships with a CHANGELOG entry, a refreshed bench-history row, and a tagged commit.

Next up: v0.17 Auto-fix. Install today; new versions land on top of the engine you already have configured.

Install alint → Track releases