Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

github.com

Post reply on HN
Print view View original

21–30 of 133 posts

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#21

Post by timhh »

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!

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#22

Post by schindlabua »

candiddevmike wrote: post #4

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?

This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#23

Post by esafak »

JoshTriplett wrote: post #19
candiddevmike wrote: post #4

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?

I think there's value in git hooks, but pre-commit is the wrong hook. This belongs in a hook that runs on attempted push, not on commit.

Run the light ones on commit, the heavy ones on push.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#24

Post by fortuitous-frog »

JoshTriplett wrote: post #19
candiddevmike wrote: post #4

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?

I think there's value in git hooks, but pre-commit is the wrong hook. This belongs in a hook that runs on attempted push, not on commit.

There's a config option for that :) https://prek.j178.dev/configuration/#default_install_hook_ty...

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#25

Post by jayd16 »

jdxcode wrote: post #15

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 i…

I think really they just need to implement some kind of plug-in or extension framework. Extensions are just not first class citizens but they really should be.

There should be a .gitextensions in the repo that the repo owners maintain just like .gitignores and . gitattributes etc etc. Everything can still be opt in by every user but at least all git clients would be able to know about, pull down, and install per user discretion.

It seems pretty basic in this day and age but it's still a gaping hole. You still need to manually call LFS install for goodness sake.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#26

Post by anentropic »

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.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#27

Post by jdxcode »

timhh wrote: post #21

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 impor…

the second the hooks modify the code they've broken your sandbox

I think wasi is a cool way to handle this problem. I don't think security is a reason though.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#29

Post by xyzzy_plugh »

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.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#30

Post by aniforprez »

esafak wrote: post #11

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?

prek is compatible with pre-commit so any hooks that can be used for pre-commit can be used with prek including the repo config file. Depending on if you're interested in buying into the existing pre-commit ecosystem, which is pretty extensive, then prek is a really good alternative
Post reply on HN