How alint compares with other repository linters

When alint is the right tool

Try it on one repository first, with the three-line config on the homepage.

Which tool for which job

These combine. A typical setup is a code linter, alint for the files and something for GitHub settings or pull-request chores.

Side by side

alint next to the three tools whose job overlaps most with it, and next to the check scripts it replaces.

In April 2026, alint 0.5.7 and Repolinter 0.11.2 were timed on the same 100,000-file tree, on an AMD Ryzen 9 3900X: on existence and content checks, Repolinter took 13.8 s where alint took 965 ms. Repolinter 0.12.0, its last release, wasn't timed. The same run's ls-lint 2.2.3 timing was wrong, because the harness ran ls-lint without its config, and it hasn't been measured again. The benchmarks page has the method.

The closest alternatives

• Repolinter

  The TODO Group's checker for the files an open-source repository should have, archived on 6 February 2026. alint has a full equivalent for 24 of the 26 checks in its default ruleset; the other 2 are off by default. Of its 19 rule types, 5 have no equivalent, among them broken-link checks and searching old commits.

  Move to alint. The Repolinter guide maps each rule type and default rule, and gives you the default ruleset as a config.

• ls-lint

  Checks file and directory names against rules such as kebab-case, snake_case or a regex, and can require that a file exists. It's a small Go binary, and alint's filename_case accepts its case names, though the two check names with several dots differently.

  Keep it if names are all you check. Add alint for the rest; the ls-lint guide starts with running both.

• pre-commit-hooks

  The pre-commit project's own set of Python hooks, 32 of them in v6.0.0, each checking or fixing one thing in the files a commit touches. alint has rules for most of the file checks, from trailing whitespace to large files; Python-only hooks such as check-ast have no equivalent.

  Either, or both. alint runs as a pre-commit hook too, and the same rules run in CI and the editor.

• Check scripts

  Kubernetes had 50 hack/verify-*.sh scripts in May 2026, and make verify ran most of them on every pull request. The reference config for it covers about two thirds of what they check: most as alint rules, and the code generators by running Kubernetes' own scripts from alint. The rest needs Go's type checker, a build or the network. Kubernetes doesn't use alint.

  Move the file checks to rules, and run the other scripts from command rules. The scripts guide pairs shell one-liners with rules.

Tools for one part of the job

Each of these does one job alint also touches, in more depth.

commitlint

Lints commit messages. It splits each message into a type, scope, subject, body and footer, and its rules check each part: type-enum, scope-enum, subject-case and so on. It runs on Node.js, usually from a Husky hook, and @commitlint/config-conventional gives you Conventional Commits in one line.

alint's git_commit_message checks a pattern, the subject length and a body for every commit since the base you give it in since:, such as a pull request's. Use commitlint for a detailed convention with allowed types and scopes.

Danger

Runs in CI and comments on the pull request. Its rules are code in a Dangerfile, in JavaScript or TypeScript, with Ruby and Swift versions too, and they can read the pull request's title, description, labels and changed lines.

Use both: alint's pair_changed_together and changeset_requires_path cover the file side of review chores, and run before the pull request exists, in pre-commit and the editor.

OpenSSF Scorecard

Scores a project's security practices from 0 to 10 on 19 checks, such as Branch-Protection, Code-Review and Signed-Releases. It reads the repository through the GitHub or GitLab API, so it sees settings that aren't in any file.

Use both. Five Scorecard checks look at files alint checks too: a security policy, a license, a dependency update tool's config, pinned actions and read-only workflow tokens. alint fails the pull request that breaks them; Scorecard grades the whole project afterwards.

actionlint and zizmor

actionlint catches mistakes in GitHub Actions workflows: syntax, types in ${{ }} expressions, action inputs, runner labels and cron schedules, with ShellCheck on run: scripts. zizmor has 41 security audits, among them template injection, excessive permissions, unpinned actions and credentials a checkout leaves behind.

Use them for workflows. alint's ci/github-actions ruleset (3 rules: pinning, token scope and a name) is a floor for repositories that run nothing else.

dependency-cruiser, import-linter and Nx

Import rules with the language's own module resolution. dependency-cruiser checks JavaScript and TypeScript against forbidden, allowed and required rules, finds cycles and orphans, and follows webpack aliases and tsconfig paths. import-linter checks Python against contracts such as layers and independence. Nx tags projects and limits which tags each may depend on.

Use them where they fit. alint's import_gate and file_graph read paths and text rather than resolving packages, which suits Protobuf, Nix and layering by path.

MegaLinter and EditorConfig

Sources

The facts about other tools come from their own documentation and repositories, read in September 2026. If one of them has changed, open an issue on GitHub.

• Repolinter
• ls-lint
• pre-commit-hooks
• commitlint
• Danger
• OpenSSF Scorecard
• actionlint
• zizmor
• dependency-cruiser
• import-linter
• Nx module boundaries
• MegaLinter
• EditorConfig

The guides go further: migrating from Repolinter maps each rule type and default rule, migrating from ls-lint ports its config, moving check scripts to alint sorts scripts into rules and scripts to keep, and the use cases cover monorepos and coding agents.