HN

Comments (97)

• Menu

  dpc_01234
  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.
• Menu

  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/nitThe VFS stuff is not quite finished yet though (it's really complicated). If anyone wants to help me with that it would be welcome!
• Menu

  jdxcode
  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.
• Menu

  esafak
  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?
• Menu

  candiddevmike
  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?
• anentropic
  I am a big fan of prek and have converted a couple of projects over from pre-commitThe 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.
• __mharrison__
  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.
• Menu

  nsm
  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?
• Menu

  fishgoesblub
  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.
• BeeOnRope
  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).
• Menu

  thayne
  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.
• Menu

  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.
• Menu

  semiinfinitely
  I always just disable pre-commit
• aaronblohowiak
  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…
• fuddle
  It would be great to see some charts on https://prek.j178.dev/benchmark/
• Menu

  WolfeReader
  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.
• Menu

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

  egorfine
  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?
• Menu

  teaearlgraycold
  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.
• evetools
  Anyone using on very big projects can vouch for the speed of things?
• iFire
  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.
• anon
  undefined
• BewareTheYiga
  This has been such a breath of fresh air. It was seamless to drop into my projects.
• h4kunamata
  "...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!!