j178/prek: a Rust drop-in replacement for pre-commit, and what it changes

The problem prek targets: pre-commit's Python dependency

pre-commit is the de facto way to run formatters, linters and secret scanners before a commit lands. Its own runtime is Python, which means the hook manager and the hooks it manages share an interpreter and an environment. On a polyglot repository that is friction: a Rust or Go project ends up needing a Python toolchain on every developer machine and in every CI image just to run a YAML formatter.

prek's answer is packaging. The README describes it as "a fast Git hook manager written in Rust, designed as a drop-in alternative to pre-commit, reimagined," and the first bullet under Features is "A single binary with no dependencies, does not require Python or any other runtime." The project is published as a Python binary wheel on PyPI as well, so the distribution channel does not force the runtime on you.

The intended audience is narrow and specific: teams with an existing pre-commit configuration who want the same hooks without the interpreter. The README states prek is "fully compatible with pre-commit configurations and hooks, so you can use it as a drop-in replacement without changing your setup." That compatibility claim is the whole pitch. If you are starting from nothing, prek is still a hook runner, but the drop-in argument does not apply to you.

How prek works: config compatibility plus its own toolchain layer

The data flow follows pre-commit's shape. A config file lists repositories, each pinned to a revision, each exposing hook ids. prek resolves those hook repositories, installs what they need, and runs the hooks against staged files or the whole tree. The README's own summary: "prek also installs and manages the tools and dependencies they need."

Where prek departs is the installation layer. The feature list names "Improved toolchain installations for Python, Node.js, Bun, Go, Rust and Ruby, shared between hooks." That matters when several hooks from different repositories all want Node: prek installs one toolchain and shares it rather than letting each hook environment pull its own copy. The README also mentions "Integration with uv for managing Python virtual environments and dependencies," which is the Python-side equivalent.

The repository layout backs this up. The Cargo workspace under crates/ includes prek-consts, prek-identify and prek-pty as separate crates, and the dependency list in Cargo.toml includes async_zip (aliased to astral_async_zip), async-compression with gzip, xz and tokio features, and axoupdater with the github_releases feature. Archive extraction and self-update from GitHub releases are first-class concerns in the codebase, not afterthoughts.

Monorepo support is the other structural difference. The README points to a workspace mode page and describes "concurrent execution for independent same-depth projects." That is a scheduling decision: projects at the same depth in the tree can run in parallel because they do not depend on each other.

Installing prek and running your first hook

The README offers many install paths. The standalone installer downloads a release binary, which is the shortest route on Linux and macOS. The version in the URL matches the current release, v0.5.3.

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/j178/prek/releases/download/v0.5.3/prek-installer.sh | sh

If your project already manages Python dependencies, the README recommends uv. Either command puts the prek binary on your PATH, and running prek with the version flag should print the installed version.

uv tool install prek

For a Node.js project, the package is published under the @j178 scope and can be added as a dev dependency. The README shows the same pattern for npm, pnpm and bun.

npm add -D @j178/prek

The README also shows a one-off run without installing, using the Node.js package directly. The output is the prek version string.

npx @j178/prek --version

With the binary installed, the first real use is to point it at your existing configuration. The README's compatibility claim means the config file does not change. Running every hook against the whole tree is the useful first check because it surfaces hook failures that a staged-files-only run would miss on a fresh clone. The README does not show this exact invocation in the excerpt above, so check the command's help output for the installed version before relying on it. The README also points to a Quick start section and to prek.j178.dev for the full command set.

Where prek is the wrong tool

The compatibility claim is broad, and broad claims are where to look for gaps. The README says prek is fully compatible with pre-commit configurations and hooks, but it does not enumerate the edge cases: hook types outside the common ones, language runtimes not in the supported list, or behaviours that depend on pre-commit's Python internals. If your configuration leans on a hook that shells into pre-commit's own Python API, the drop-in guarantee is untested by anything in the README.

There is also no documented rollback. The README covers installation thoroughly and says nothing about uninstalling prek or reverting the Git hook shims it writes into .git/hooks. If you switch and something breaks, the README does not tell you the supported way back. That is a real gap for a tool that modifies repository state.

The project is new. The README says so directly: "Although prek is pretty new, it's already powering real-world projects like CPython, Apache Airflow, FastAPI." Version 0.5.3 is below 1.0, and the pyproject.toml rooster configuration notes "We do not use the major version number yet" with minor_labels set to breaking. Breaking changes are expected on minor releases, so pin your version in CI rather than tracking latest.

Finally, prek is a hook runner. It is not a linter, not a formatter, and not a replacement for the tools your hooks invoke. If you do not already have a pre-commit configuration, adopting prek does not give you one.

prek vs lefthook and the rest of the field

The obvious comparison is lefthook, which also runs Git hooks from a single binary and also avoids a Python runtime. The difference is configuration format and ecosystem. lefthook uses its own YAML schema and its own hook definitions. prek reads pre-commit's .pre-commit-config.yaml and reuses pre-commit's hook repositories, which is why the README can call it a drop-in replacement. If you have a working pre-commit setup, prek is a binary swap. Moving to lefthook means rewriting the configuration and re-sourcing your hooks.

The second comparison is pre-commit itself. pre-commit is the reference implementation, it is mature, and its behaviour is the behaviour everyone tests against. prek trades that maturity for a dependency-free binary and faster execution, and the README links to a benchmark page rather than quoting numbers, so the performance claim is the project's own and should be verified on your workload.

There is a third option worth naming: running hooks directly from a Makefile or a shell script. That removes the framework entirely and with it the caching, the per-hook environments and the revision pinning. For a repository with two hooks it is defensible. For anything larger, you lose the thing pre-commit and prek both provide, which is reproducible hook environments pinned by revision.

Maintenance, upgrade cost and the MIT licence

The repository is not archived. The last push was on 2026-09-21, and releases have been frequent: v0.5.1 on 2026-09-01, v0.5.2 on 2026-09-02, v0.5.3 on 2026-09-13. That release cadence is the practical upgrade cost. With minor versions carrying breaking changes, a floating version constraint will eventually break your CI, and the CHANGELOG.md at the repository root is where the breaking changes are listed.

prek is MIT licensed, and both Cargo.toml and pyproject.toml declare license = "MIT". The pyproject.toml also sets license-files to ["LICENSE", "licenses/*"], so the repository carries a licenses directory alongside the main file. MIT is permissive: it allows commercial use and modification with attribution. That is a statement about the licence text, not legal advice, and if you redistribute prek inside a product you should read the LICENSE file and the licenses/ directory yourself.

One distribution detail matters for supply chain review. The standalone installer pipes a shell script from a GitHub release into sh, which is the standard pattern for Rust CLI tools but does mean the installer itself is not verified by a package manager. If that is a problem for your environment, the Homebrew, Nix, Conda, Scoop, Winget, PyPI and npm paths all exist, and the README lists them.

Editorial conclusion

Adopt prek if you already have a .pre-commit-config.yaml and want the hook runner out of your Python environment, or if you maintain a monorepo where independent same-depth projects can run concurrently. Do not adopt it if your hooks depend on pre-commit behaviour the README does not cover, or if you need a documented rollback path, because the README does not document one. Before switching, run the same hooks on a branch with both tools and compare their output on the same commit.

Frequently asked questions

Official sources

1. j178/prek on GitHub
2. License: MIT
3. Project website
4. README
5. Releases