Skip to content

Bundled rulesets

alint ships 22 bundled rulesets compiled straight into the binary, with no network round-trip. They are the on-ramp: instead of hand-writing rules, you add one extends: line and inherit a curated set, from oss-baseline (a Repolinter migration starting point) to per-language, monorepo, CI, hygiene, compliance, and agent-aware sets. Two properties make them safe to adopt broadly: every rule is fact-gated, so a ruleset applies itself only where it belongs, and everything it declares is overridable field-by-field from your own config.

A bundled ruleset's rules are fact-gated, so extending it is a no-op where the fact does not hold One extends line pulls in three bundled rulesets. oss-baseline always applies. rust@v1 is gated on facts.has_rust and fires because the repo has Rust. go@v1 is gated on facts.has_go and stays dormant because the repo has no Go. Every inherited rule can be overridden in your own config. one extends line 22 bundled rulesets your .alint.ymlextends: oss-baseline, rust@v1, go@v1 repo facts: has_rust = true, has_go = false oss-baseline@v1always appliesapplies rust@v1when facts.has_rustfires go@v1when facts.has_godormant a ruleset applies itself only where its facts hold override any inherited rule's level in your own config

The 22 sets fall into a few families: oss-baseline (the migration starting point for the archived Repolinter); seven language sets (rust, python, node, go, java, php, dotnet); a monorepo base with Cargo, pnpm, and Yarn workspace overlays; ci/github-actions; tooling/editorconfig; hygiene sets (hygiene/lockfiles, hygiene/no-tracked-artifacts); compliance (compliance/reuse, compliance/apache-2) and apache/governance; docs/adr; and the two agent-aware sets (agent-context, agent-hygiene). Each is a hand-curated group of rules, compiled into the binary, referenced as alint://bundled/<name>@v1. alint init scaffolds a starting config for you: it always extends oss-baseline and adds a language set for each stack it auto-detects (Rust, Node, Python, Go, or Java). The php and dotnet sets ship too but are not auto-detected, so add those to extends: by hand.

The reason you can extend a language set without worrying whether it fits: each rule inside carries a when: gate over a per-run fact. rust@v1’s rules are when: facts.has_rust, so extending it in a repo with no Rust is a silent no-op, not a wall of irrelevant findings. Adopt the whole set and it activates itself where it applies. This is why oss-baseline plus every language set is a reasonable default: the gates keep each one dormant until its stack shows up. In a polyglot monorepo the gating goes one level finer: a language set’s per-file rules also carry a scope_filter: { has_ancestor: <manifest> }, so rust@v1’s rules fire only inside a directory that actually contains a Cargo.toml, never across an unrelated package.

Add the sets you want to extends:, then tune them in your own config. A rule you inherit is overridden field-by-field by id: name the same id and set just the fields you want to change (a level, a path, a message), and the rest of the rule stays as the bundle defined it, exactly like config layering merges a drop-in. What a bundled ruleset does not gain is extra execution privilege: reached through extends:, it sits below the same trust boundary as any fetched ruleset, so it cannot declare spawning rules, custom: facts, allow_out_of_root, or a baseline any more than a remote one can. What it gains instead is provenance: shipping in the binary, it resolves offline and is byte-identical to the release, with nothing to fetch or hash-pin.

Extend the OSS baseline and the Rust set, and downgrade one inherited rule to a warning while a repo catches up:

version: 1
extends:
- alint://bundled/oss-baseline@v1
- alint://bundled/rust@v1
rules:
- id: readme-exists
level: warning

alint list shows the union of the inherited rules with your override applied; alint check runs the Rust rules only if the tree actually has Rust.