HN Reader

BTW. Pre-commit hooks are the wrong way to go about this stuff.

I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do anything special.

I have something a bit like that implemented in SelfCI (a minimalistic local-first Unix-philosophy-abiding CI) https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX... and it replaced my use of pre-commit hooks entirely. And users already told me that it does feel like commit hooks done right.

I have also been working on an alternative written in Rust, but in my version the hooks are WASI programs. They run on a virtual filesystem backed by the Git repo. That means a) there are no security issues (they have no network access, and no file access outside the repo), b) you can run them in parallel, c) you can choose whether to apply fixes or not without needing explicit support from the plugin, and most importantly d) they work reliably.

I'm sure this is more reliably than pre-commit, but you still have hooks building Python wheels and whatnot, which fails annoyingly often.

https://github.com/timmmm/nit

The VFS stuff is not quite finished yet though (it's really complicated). If anyone wants to help me with that it would be welcome!

I think it was a massive mistake to build on the pre-commit plugin base. pre-commit is probably the most popular tool for pre-commit hooks but the platform is bad. My main critique is that it mixes tool installation with linting—when you will undoubtedly want to use linters _outside_ of hooks. The interface isn't built with parallelism in mind, it's sort of bolted on but not really something I think could work well in practice. It also uses a bunch of rando open source repos which is a supply chain nightmare even with pinning.

pre-commit considered harmful if you ask me. prek seems to largely be an improvement but I think it's improving on an already awful platform so you should not use it.

I know I am working on a competing tool, but I don't share the same criticism for lefthook or husky. I think those are fine and in some ways (like simplicity) better than hk.

I use http://hk.jdx.dev/, which is based on https://pkl-lang.org/ and Rust, as it integrates with http://mise.jdx.dev/.

Is prek much better?

I struggle to see value with git hooks. They're an opt-in, easily opt-out way of calling shell scripts from my understanding--you can't force folks to run them, and they don't integrate/display nicely with CI/CD.

Why not just call a shell script directly? How would you use these with a CI/CD platform?

For folks using devenv: prek is the default used for devenv's git-hooks since November 2025

https://devenv.sh/blog/2025/11/26/devenv-111-module-changelo...

I am a big fan of prek and have converted a couple of projects over from pre-commit

The main advantage for me is that prek has support for monorepo/workspaces, while staying compatible with existing pre-commit hooks.

So you can have additional .pre-commit-config.yaml files in each workspace under the root, and prek will find and run them all when you commit. The results are collated nicely. Just works.

Having the default hooks reimplemented in Rust is minor bonus (3rd party hooks won't be any faster) and also using uv as the package manager speeds up hook updates for python hooks.

Really enjoying using prek.

Dedicated a whole chapter to it in my latest book, Effective Testing.

The trend of fast core (with rust) and convenient wrapper is great while we are still writing code.

Am I alone in that I never have had an issue with performance with pre-commit? granted I don't work on projects the size of the Linux kernel, but I haven't had any complaints.

It doesn’t seem like this solves the main issues with pre-commit hooks. They are broken by design. Just to name 2, they run during rebase and aren’t compatible with commits that leave unstaged files in your tree.

Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following?

* CI (I understand pre-commit shifts errors left)

* in editor/IDE live error callouts for stuff like type checking, and auto-formatting for things like "linters".

Do you run tests? How do you know _which_ tests to run, and not just run every test CI would run, which could be slow?

Another commenter is currently down voted for something similar, but I'll share my controversial take anyways: I hate pre-commit hooks.

I loathe UX flows where you get turned around. If I try to make a commit, it's because that I what I intend to do. I don't want to receive surprise errors. It's just more magic, more implicit behavior. Give me explicit tooling.

If you want to use pre-commit hooks, great! You do you. But don't force them on me, as so many projects do these days.

How does prek handle pre-push hooks? I.e. how does it determine the list of modified files.

This is a long standing sore point in pre-commit, see https://github.com/pre-commit/pre-commit/issues/860 and also linked duplicates (some of which are not duplicates).

I always just disable pre-commit

So if you are using multiple languages to have scripts that run off your pre-commit hook, this is like a package and language runtime management system for your pre-commit hook build system? Rather, I think this is a reimplementation of such a system in rust so it can be self contained and fast.

This is the kind of thing I see and I think to myself: is this solving a problem or is this solving a problem that the real problem created?

Why is your pre-commit so complicated that it needs all this? I wish I could say it could all be much simpler, but I’ve worked in big tech and the dynamics of large engineering workforces over time can make this sort of thing do more good than harm, but again I wonder if the real problem is very large engineering teams…

It would be great to see some charts on https://prek.j178.dev/benchmark/

Would need auto-fix & commit capabilities to really replace lefthook or lint-staged for me. https://github.com/j178/prek/issues/1051

My big problem with pre-commit is that it doesn't have any way for you to have your own commit hoos that run in addition to the hooks that are part of the repo, and the author of it is hostile to any suggestion of supporting that. Heaven forbid that I want to run something on commit that other developers who work on the repo don't want to.

Not just faster than pre-commit, and totally compatible. Also with more features.

I like pre-merge hooks. They're great.

Pre-commit and pre-push hooks serve the purpose of keeping code isolated to a developer's machine. This is a recipe for disaster. You will run into situations where important work isn't accessible since a developer couldn't commit/push their code and the machine was lost or damaged. I've seen it happen.

Emojis as bullet points in the README make me think this was generated with an LLM. No thanks

What difference does it make that it's written in Rust? Why is that so much a selling that it made it into the title?

Anyone using on very big projects can vouch for the speed of things?

Title should be: "[Rust] Prek: A Rust-written, better, faster, drop-in pre-commit replacement, engineered in Rust"

Just to make clear it's been written -- sorry, ENGINEERED -- in Rust.

I don't understand. The whole point of pre-commit is it's a gateway to the operating system and also creating a ecosystem of pre integration continuous integration scripts. Scripts that are not rust.

This has been such a breath of fresh air. It was seamless to drop into my projects.

"...in Rust"

Is enough to don't even open the link! Everything right now seems to have an urgent need to be developed into Rust, like why???

Just like kubernetes, many companies followed the kubernetes hype even when it was not needed and added unnecessary complexity to a simple environment.

Now it is Rust time!!