Roadmap: what's shipped and what's next
alint is planned in versions with a fixed scope and no dates, because a missed date does more harm than none. Work that doesn't fit a version moves to a later one, and the plan changes in public commits to the alint repository.
Planned next
- v1.0
Stability
The config format will stop changing, the public API of the
alint-corelibrary will be frozen, and the docs will keep a version for each release. - Later
Plugins and duplicate code
Plugins compiled to WebAssembly, run in a sandbox and installed from a signed registry, and a duplicate-code detector that works across languages. Neither has a version yet.
Recently shipped
- v0.1811 October 2026
A security and correctness audit
A review of the whole codebase, then a second, adversarial pass over its fixes. A shared ruleset can't hide fields from alint's trust checks, can't skip files with
ignore:or read your environment, and a crafted YAML or XML file can't run alint out of memory. New:markdown_links_resolvechecks the links in your Markdown, andexpect_matchesfails a rule whose paths match nothing. The editor extensions pick the nearest config for each file. The v0.18.1 patch makes the per-file content checks faster than in v0.17 and stops the installer failing on busy shared CI runners. v0.18.2 makes alint's own output escape every invisible character its bidi and zero-width rules flag, and moves.envparsing into the newadotenvcrate. - v0.171 October 2026
More fixes
Much more of what alint flags now has a fix. Safe fixes apply by default and riskier ones wait for a flag. Fixes rewrite text in place, set or remove values in JSON, YAML, TOML and XML without disturbing the formatting, repair permissions and shebangs, and sort blocks and headers. alint checks each edit against the rule that asked for it and says what it couldn't fix.
- v0.162 September 2026
More config formats
XML joins the formats every value rule can read, and
.env, Java.properties, INI and HCL (Terraform) files get rules of their own. New rules check that a key isn't set. Every config parser now has limits, so a crafted file can't hang alint or run it out of memory.
v0.1 to v0.15 are on the full roadmap, and every release's changes are in the changelog.
What alint won't do
alint checks the files in a repository and the values inside them. It doesn't parse the code in those files. For these jobs, use a tool built for them:
| Out of scope | Use instead |
|---|---|
| Checks that parse your code: names, unused imports, types | Your language's linter: ESLint, Clippy, Ruff, golangci-lint, mypy |
| Security analysis of code: tainted data flow, injection, dangerous APIs | Semgrep, CodeQL |
| Security policy for Terraform, Kubernetes and Docker resources | Checkov, Conftest, Trivy |
| Secrets such as API keys and tokens in files and git history | gitleaks, TruffleHog |
| Installing and running a set of other linters, each with its own toolchain | MegaLinter, pre-commit, lintrunner |
| Running code generators to check what they produce | Your build. alint runs one only if your own config adds a generated_file_fresh or command_idempotent rule |
| Dependencies between modules and packages: unused dependencies, version conflicts, package cycles | cargo-deny, knip, madge, bazel mod |
Two jobs near that line are in scope. The commit rules check every commit in a range: messages, sign-offs, fixups, authors and GPG signatures. And file_graph with require: acyclic finds cycles between files. Compare covers the tools whose job overlaps with alint's.
How versions are planned
- A larger feature starts as a design document in docs/design before any code.
- A new rule kind gets built when several repositories need it. A list in the alint repository counts the repositories behind each candidate.
- Questions and feature requests go to GitHub discussions, and bugs to GitHub issues.
Watch GitHub releases for new versions, or subscribe to the release feed.