mrkeyoor.com_
Sat 08 Aug 20:59 UTC
PyPICLI & Toolingupdated 08 Aug 2026

prek

prek is a Rust command-line manager for Git hooks and a practical alternative to Python's pre-commit. It reads existing .pre-commit-config.yaml files, installs isolated hook tools and runtimes, runs checks on staged files or in CI, and installs Git hook shims. It also adds a native prek.toml format, built-in Rust versions of common checks, shared toolchain caches, concurrent hook priorities, managed runtime downloads, and workspace discovery for monorepos with nested configurations.

Verdict

prek is the most compelling pre-commit replacement when environment setup time or monorepo coordination is a real cost. Keep pre-commit when exact upstream behavior and mature interface stability matter more than speed, and avoid all remote hook managers unless you are prepared to review the code they execute.

API stability3/5Compatibility with .pre-commit-config.yaml and accepted aliases for install-hooks, auto-update, clean, and gc gives existing projects a useful stable base. The project also documents preferred command replacements instead of silently breaking them. It remains version 0.4.12, however, and intentionally differs in file identification, reorganizes commands, omits hazmat, and is rapidly adding groups, priorities, managed languages, workspaces, TOML, builtins, and security checks. Treat minor upgrades as developer-tool changes that deserve CI testing.
Docs5/5The dedicated site has separate installation, quick-start, migration, compatibility, differences, configuration, CLI reference, environment variables, language support, workspace, built-in hook, authoring, integration, debugging, FAQ, benchmark, and changelog pages. Crucially, it states non-compatible behavior, unsupported commands, fast-path exceptions, cache locations, project discovery rules, concurrency assumptions, and builtin caveats. That is the right level of honesty for a tool that runs code during commits, even though the fast release pace means readers must stay on the versioned current site.
Maintenance5/5Version 0.4.12 was published on August 3, 2026, and the repository was pushed on August 8, 2026. PyPI carries compiled wheels for a notably broad matrix including glibc, musl, x86, Arm, s390x, RISC-V, Windows, and both macOS architectures, plus a source archive. The project is neither archived nor disabled, has active releases and documentation, and its current 8,217 GitHub stars indicate unusually fast contributor and user attention. The main maintenance risk is velocity, not inactivity.
Ecosystem4/5prek can consume the established pre-commit configuration and hook-repository ecosystem while adding installation through PyPI, npm, Homebrew, Cargo, Nix, Conda, Scoop, Winget, mise, standalone binaries, and a dedicated GitHub Action. Its recorded usage is about 6.1 million downloads per week, and the README lists adoption in large Python and polyglot projects. It loses one point because prek-specific TOML, builtins, groups, glob mappings, and workspace behavior are not portable back upstream, and the project itself is still young.

Use it if

  • Your repository already uses pre-commit configuration and environment setup or hook startup is noticeably slow
  • Your polyglot team wants one binary to provision hook runtimes without requiring Python just to run the manager
  • Your monorepo needs separate nested hook configurations, scoped file sets, and concurrent execution for independent projects
  • You want offline built-in checks for common whitespace, syntax, filename, secret-key, and merge-conflict mistakes
Skip it if

Setup reality

The PyPI package is a delivery wrapper for a compiled Rust executable, not a Python application. Version 0.4.12 publishes wheels for many Linux, macOS, and Windows targets and declares Python 3.8 or newer for that installation route, with no Python runtime dependencies. Other supported routes include uv, pipx, Homebrew, npm, Cargo, Nix, Conda, Scoop, Winget, and standalone installers. If no binary matches and you build from source, the README requires Rust 1.95 or newer. Git is mandatory, and real hooks still need their own tools. The first run clones hook repositories, resolves revisions, downloads managed runtimes where configured, and creates environments under ~/.cache/prek, so it is much slower and more network-dependent than later runs. Cache that directory in CI only when cache keys include operating system, architecture, prek version, and config content. A remote hook is executable supply-chain code. Pin reviewed tags or commit SHAs, use update checks deliberately, and do not treat a hook repository as harmless configuration. Existing pre-commit users can keep YAML, replace commands, then run prek install -f once to replace the old shim. Without -f, an existing hook can block installation; with it, you are intentionally taking ownership of that hook file. prek run checks staged files by default, while CI normally needs --all-files or an explicit range. Hooks that modify files exit nonzero so the developer can inspect and restage changes. Workspace discovery walks nested configuration files, respects ignore rules, and caches the result; a newly added project may require --refresh. Parent and child projects can both process the same file unless the child is orphaned. Concurrent hooks must not mutate shared lockfiles, caches, or sibling project state. Keep YAML and upstream-compatible features if developers may switch back to pre-commit; prek.toml, repo: builtin, workspace mode, and prek glob mappings commit the repository to prek.

Patterns

Configure two hooks in prek.tomlconfigure-basic-hooks

[[repos]]
repo = "https://github.com/pre-commit/pre-commit-hooks"
rev = "v6.0.0"
hooks = [
  { id = "check-yaml" },
  { id = "end-of-file-fixer" },
]

prek.toml is native to prek and will not run with upstream pre-commit. Keep YAML when portability matters.

Run an existing pre-commit YAML configurationreuse-precommit-config

prek validate-config .pre-commit-config.yaml
prek run --all-files

Common configurations work unchanged, but check the compatibility page for behavioral differences and unsupported hazmat commands.

Install the Git hook shiminstall-git-hook

prek install

If pre-commit already owns the hook, the migration guide calls for prek install -f once. Review the existing hook before forcing replacement.

Uninstall the managed Git hookremove-git-hook

prek uninstall

This removes prek's integration, not the tool environments cached under ~/.cache/prek.

Run hooks against staged filesrun-staged-files

git add src tests
prek run

Fixing hooks may modify files and return nonzero. Inspect and stage the modified files before committing again.

Run every hook against every tracked filerun-entire-repository

prek run --all-files

Use this for initial adoption and ordinary CI. A plain prek run is centered on the staged-file workflow.

Run one hook on explicit filesrun-selected-files

prek run check-yaml --files .github/workflows/ci.yml config/app.yml

The hook's own files, exclude, and type filters still determine whether each explicit path is eligible.

Preview hooks and files without executingpreview-selection

prek run --all-files --dry-run

Dry-run helps debug selection, but it does not prove that tool environments install or hooks pass.

Use Rust-native hooks without a remote repositoryuse-offline-builtins

repos:
  - repo: builtin
    hooks:
      - id: trailing-whitespace
      - id: check-merge-conflict
      - id: detect-private-key

repo: builtin avoids cloning and environment setup, but makes the YAML incompatible with upstream pre-commit.

Fail CI when hook revisions need attentioncheck-hook-updates

prek update --check

This previews updates and exits nonzero without rewriting configuration, which is safer than automatic unreviewed upgrades in CI.

Target one monorepo project and skip a hookrun-workspace-project

prek run frontend/ --skip frontend:format

The trailing slash marks a project selector. Without it, prek interprets the token as a hook ID.

Inspect and prune cached environmentsinspect-cache

prek cache dir
prek cache size
prek cache gc --dry-run
prek cache gc

gc removes unused repositories, environments, and toolchains. Use dry-run first on developer or shared CI caches.

Alternatives

PackageRegistryPick it when
pre-commitPyPIYou prioritize the original implementation, strict configuration portability, and the largest established hook-manager community
lefthookPyPIYou want a fast compiled hook runner with its own simpler configuration and do not need pre-commit repository compatibility
lint-stagednpmYou have a Node-centered repository and only need package scripts run against staged files