alint roadmap

Where alint stands today

Latest release: v0.9.20. 60 rule kinds across 13 families, 19 bundled ecosystem rulesets, 12 auto-fix ops, 8 output formats including agent-aware. 21 config-authoring pitfalls catalogued and prevented across the toolchain (schema at edit time, parse error at load time, runtime audit at PR time, smoke-test fixture at commit time). 30 production OSS case studies under examples/: 20 single-language (P2a) plus 10 polyglot monorepos (P2b Waves 1+2: NixOS/nixpkgs, bazel, TensorFlow, apache/spark, vscode, angular, istio, dotnet/runtime, protobuf, flutter). Sub-second on 100K-file repos (~1.1 s on a 100K-file workspace bundle, ~12 s at 1M files; nixpkgs at 39,101 files runs the full 79-rule pass in 273 ms wall-clock).

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

v0.10: LSP server next

The first user-visible IDE / agent integration. v0.9 was engine-internal performance work; v0.10 turns the per-file dispatch hot path (built out in v0.9.3-v0.9.6) into a single-file re-evaluation contract that an LSP server can drive cheaply.

Headline features

• Inline diagnostics. alint lsp speaks LSP 3.17 over stdio. textDocument/didChange triggers debounced per-file evaluation; textDocument/didSave triggers cross-file re-check. Same violation list as alint check, surfaced inline.
• Hover with rule docs. textDocument/hover over a violation marker shows the rule's policy_url, message, and a one-line summary. Same content the docs site renders.
• Code actions. textDocument/codeAction emits "Apply fix" for rules with a Fixer (12 fix ops today) plus "Add rule to ignore" for any violation. Editor handles the buffer rewrite via the standard WorkspaceEdit flow.
• VS Code extension. A thin extension that bundles the alint lsp binary and registers the LSP client. Coming to the marketplace alongside the v0.10 release.

v0.10 ship-target rule kinds

Each crossed the saturation threshold (≥3 distinct source repos surface the same need) in the case-study sweep.

v0.10 design candidates

≥2 sources or shape-clarity wins; ship-status pending design pass.

• *_path_contains (set-membership shorthand): helm, deno, bazel. Resolves pitfall #17 directly.
• pair_inverse (every partner traces back to a primary): ruff, angular. Snapshot freshness; covers cargo insta --unreferenced=reject and angular goldens parity.
• command_idempotent mode: ruff, prettier. mdformat, markdownlint, prettier, ruff-format, dprint-check all share this shape.
• for_each_leaf_dir / iter.is_leaf accessor: prettier, rust, ruff. Extends existing rather than new kind.
• balanced_delimiters + file_pair_block_match: rust, cpython. tidy::rustdoc_css_themes + cpython Argument Clinic block markers.
• json_schema_passes config-shape mode: k8s, turbo. Replaces hand-rolled argv:-shape checks.
• dir_name_matches_field: turbo, next.js. Per-package name in package.json equals directory name.
• file_hash_not / hash-denylist: Repolinter migration. Repolinter's file-hash-not axiom.
• multi_doc_mode: knob on yaml_path_* (error / first / every): istio. Resolves pitfall #21.
• value_extractor: block on cross_file_value_equals: istio. Resolves pitfall #20.

v0.10 bundled rulesets

• apache/governance@v1: LICENSE + NOTICE + KEYS + RAT discipline. 3 Apache TLPs converge (arrow + spark + airflow): 9 of 12 governance artefacts shared. Replaces hand-rolled Apache-RAT shellouts. Ship-target.
• dotnet@v1: surfaced by dotnet/runtime. Adopter surface: every dotnet/*, every Azure SDK, every microsoft/* .NET project. Ship-target.
• python/pep-621-shape@v1 (uv): design candidate.
• rust/cargo-release-conventions@v1 (clap): design candidate.
• cncf/owners@v1 (helm; OWNERS-file shape per k8s sig conventions): design candidate.
• ruby@v1 / swift@v1 / objective-c@v1 / erlang@v1 / elixir@v1 (Repolinter migration): design candidates.

v0.10 design pass →

v0.11: WASM plugins after that

The plugin tier that completes alint's extensibility story. The command plugin (tier 1, shell out per matched file) shipped in v0.5.1 and has been the only plugin tier so far. v0.11 adds:

• wasm plugin kind. wasmtime host, stable WIT interface. Author plugins in any language that compiles to WASI (Rust, Go, TypeScript via Javy, Python via componentize-py).
• Plugin sandbox. Full filesystem isolation by default (no host-fs access; the engine pipes file content into the plugin and reads structured violations back).
• Plugin registry scaffolding. Signature verification for community plugins; the existing SRI-pinned extends: URL pattern generalises naturally.

v0.11 flagship rule kind

• cross_language_implementation_complete. Every type in a schema spec has a per-language test fixture. 5 distinct sources (arrow, TensorFlow, protobuf, angular, flutter) across 3 distinct topologies: data-format-driven (arrow's format/Schema.fbs + 6 language bindings; TF's 1,185 textproto goldens locking 10 API-bearing language surfaces; protobuf's 10 in-tree language bindings + 1 spun-out = ~45 cross-language assertions one rule would express), within-language source↔golden (angular), and platform-driven (flutter's 6 native-OS embedders). The rule kind that justifies the polyglot positioning in one primitive.

v0.11 design pass → (promoted from internal ROADMAP when v0.11 design opens)

Post-launch ongoing work

On the table without a fixed version slot.

• MCP server. Model Context Protocol lets agents query tools directly. An alint MCP server could expose get_rule_doc(rule_kind), validate_config(yaml), and suggest_rules_for(repo_path) for agent-native integration without an editor in the loop.
• Polyglot drip content. Additional polyglot monorepo case studies beyond the 10 P2b shipped (queued: nx, electron, beam, prisma, temporal, grafana, cockroachdb, directus, supabase, terraform). Each ships as an examples/<owner>-<repo>/ case study. Demand-drives the post-v0.11 rule-kind backlog.
• alint init enhancements. Detect existing tooling (.eslintrc, Makefile targets, verify-*.sh directories) and propose a starter .alint.yml that matches the repo's existing conventions. Feeds the migration-guide story.
• Versioned docs. A /docs/v0.10/ switcher would let users on older versions land on accurate pages.

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.

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.