11 ms·

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

291 points by fortuitous-frog 8mo ago

BewareTheYiga 8mo ago
This has been such a breath of fresh air. It was seamless to drop into my projects.
rurban 8mo ago
Not just faster than pre-commit, and totally compatible. Also with more features.
- verdverm 8mo ago
  [flagged]
candiddevmike 8mo ago
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?
- esafak 8mo ago
  The value is in finding out something is going to fail locally before pushing it. Useful for agents and humans alike.
- szenrom 8mo ago
  I tend to work the other way around - what is defined in CI steps gets added to pre-commit. Several tools have already existing configurations or you can use local mode. Sure, I can't force people to use it but it saves them time as CI would fail anyway.
- thoughtpalette 8mo ago
  You can obviously bypass them, but having precommit hooks to run scripts locally, to make sure certain checks pass, can save them from failing in your pipeline, which can save time and money. From an org standpoint you can have them (mandate?) as part of the developer experience. (Our team doesn't use them, but I can see the potential value)
  - lukasgraf 8mo ago
    I never understood this argument. The checks in those pre-commit hooks would need to be very fast - otherwise they'd be too slow to run on every commit. Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail. But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There I can see what gets changed, and react to it. Pre-commit hooks sit in such a weird place between where I author my code (editor) and the last line of defense (CI).
    - Marsymars 8mo ago
      > Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail. That's still multiple minutes compared to an error thrown on push - i.e. long enough for the dev in question to create a PR, start another task, and then leave the PR open with CI failures for days afterwards. > But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There are substantial chunk of fast checks that can't be configured in <arbitrary editor> or that require a disproportionate time investment. (e.g. you could write and maintain a Visual Studio extension vs just adding a line to grep for pre-commit)
- throw20251220 8mo ago
  I like my pre-receive hooks.
- forgotpwd16 8mo ago
  Besides during commit, pre-commit/prek can run all hooks with `run`. So in CI/CD you can replace all discrete lint/format tool calls with one to pre-commit/prek. E.g. https://github.com/python/cpython/blob/main/.github/workflows/lint.yml https://github.com/python/cpython/blob/main/.github/workflow....
  - candiddevmike 8mo ago
    This just seems like calling a shell script with extra steps. I have a shell utility similar to make that CI/CD calls for each step (like for step build, run make build) that abstracts stuff. I'd have Prek call this tool, I guess, but then I don't get what benefit there is here.
- fortuitous-frog 8mo ago
  They're very commonly used in CI. There are dedicated GitHub actions for pre-commit and prek, but most commonly people just invoke something like `prek run --all-files` or `pre-commit run --all-files` in their typical lint CI jobs. The prek documentation has a list of many large projects (such as CPython and FastAPI, to name a few) who use it; each link is a PR of how they integrated it into CI if you want to see more: https://prek.j178.dev/#who-is-using-prek https://prek.j178.dev/#who-is-using-prek
- BeeOnRope 8mo ago
  They integrate well with CI. You run the same hooks in CI as locally so it's DRY and pushes people to use the hooks locally to get the early feedback instead of failing in CI. Hooks without CI are less useful since they will be constantly broken.
  - candiddevmike 8mo ago
    Why wouldn't I just call the same shell script in CI and locally though? What's the benefit here? All I'm seeing is circular logic.
    - aniforprez 8mo ago
      The point is enforcement. If there's a newcomer to developing your repo, you can ask them to install the hooks and from thereon everything they commit will be compatible with the processes in your CI. You don't need to manually run the scripts they'll run automatically as part of the commit or push or whatever process
    - esafak 8mo ago
      Yes, you can run the CI script locally so you detect errors faster.
    - Marsymars 8mo ago
      pre-commit provides a convenient way to organize running a collection of shell scripts.
    - BeeOnRope 8mo ago
      If you had a shell script hook, yes you would also run that in CI. Are you asking what advantage pre-commit has over a shell script? Mostly just functionality: running multiple hooks, running them in parallel, deciding which hooks to run based on the commit files, "decoding" the commit to a list of files, offering a bunch canned hooks, offering the ability to write and install non-shell hooks in a standard way.
    - chippiewill 8mo ago
      The pre-commit tool (which prek is based on) has a large ecosystem of off the shelf checks for various language linters and other checks and a convenient way of writing them (including working out which files have changed and which checks to run based off of that) The benefit to many of having them as a hook is that you discover it's broken before you pushed your changes, and not when you finally get around to checking the CI on your branch and realising it failed after 30s. There is of course no reason why you have to have it installed as a precommit hook - many people prefer to run it manually, and the pre-commit tool/prek allows for that.
- JoshTriplett 8mo ago
  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.
  - esafak 8mo ago
    Run the light ones on commit, the heavy ones on push.
  - fortuitous-frog 8mo ago
    There's a config option for that :) https://prek.j178.dev/configuration/#default_install_hook_types https://prek.j178.dev/configuration/#default_install_hook_ty...
  - anttihaapala 8mo ago
    formatting should definitely be in pre-commit though, otherwise you'll destroy diffs.
  - Marsymars 8mo ago
    "pre-commit the tool" supports the pre-push hook (as well as the various other hooks).
- schindlabua 8mo ago
  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.
  - esafak 8mo ago
    You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.
    - schindlabua 8mo ago
      I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits. Slow hooks are also not a problem in projects I manage as I don't use them.
      - esafak 8mo ago
        No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge. > Slow hooks are also not a problem in projects I manage as I don't use them. You bypass the slow hooks you mentioned? Why even have hooks then?
        schindlabua 8mo ago
        I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.
        deleted 8mo ago
        [deleted]
        8mo ago
- pxc 8mo ago
  I think of Git hooks as a useful guiderail for myself that I share with others. They sometimes help me reduce the length of iteration cycles for workflows (which I generally don't like) where one typically commits before running/deploying (e.g., most of my team's Terraform repos). > you can't force folks to run them I think it's useful to be able to disable things like this when debugging or reconfiguring them. I sometimes disable the ones I've set up for myself, then reenable them later. > Why not just call a shell script directly? Because it's manual; I have to remember to do it each time. But there's no reason not to have a script you can invoke in other ways, if that's something you want. > How would you use these with a CI/CD platform? The thing that sets up your environment also installs the git hooks configuration, and/or you can have it invoke specific hooks via CLI.
fishgoesblub 8mo ago
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.
- worldsayshi 8mo ago
  I've used pre-commit very sparingly but it has happened and I also have no idea why this project need to exist? Why would pre-commit ever lead to performance problems? I get that the processes that are hooked in can be long running but the pre-commit itself? Why would it take any time at all?
- globular-toast 8mo ago
  Never had a problem. It adds negligible time to each commit and I have several hooks in use. Running tests takes several orders of magnitude more time.
- chippiewill 8mo ago
  It depends on the hooks you're using and how many of them. For some languages there are some rather slow hooks, and using it on a big monorepo can take a while (a full run across my work's main repo takes minutes). If you update python based hooks all the time then installing and creating the virtualenvs can be slow too which prek speeds up.
- epage 8mo ago
  For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.
deleted 8mo ago
[deleted]
esafak 8mo ago
I use http://hk.jdx.dev/ http://hk.jdx.dev/, which is based on https://pkl-lang.org/ https://pkl-lang.org/ and Rust, as it integrates with http://mise.jdx.dev/ http://mise.jdx.dev/. Is prek much better?
- aniforprez 8mo ago
  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
- sangeeth96 8mo ago
  Love mise, didn't know about hk. Will check this out but don't think $WORK (or me) needs more than lefthook at the moment, which we're quite happy with. Wonder if there are comparisons/example projects that showcases the unique value propositions.
  - aniforprez 8mo ago
    Correct me if I'm wrong but lefthook doesn't run its hooks exclusively on the staged changes IIRC. pre-commit, and prek by extension, have a process to stash the unstaged changes using git and running the code only on the staged files. Last I used it, lefthook ran on every file regardless of git status. This annoyed me because I'd have a few stray files that were not ready to be checked in or tracked that would trigger failures in lefthook. At the time this also made some hooks run slower since it would run on every single file but I think most linters have become significantly faster now.
    - mm263 8mo ago
      Please look at the example that is literally on the front page of the lefthook website: https://lefthook.dev/ https://lefthook.dev/
      - 8mo ago
jdxcode 8mo ago
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.
- jayd16 8mo ago
  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.
- pxc 8mo ago
  > My main critique is that it mixes tool installation with linting If you use a tool like this via Devenv instead of using its built-in mechanisms for installing tools: - you can add a linter without putting it on your path - you can put a linter on your path without enabling any git hooks for it - if you are already using a linter in a git hook, adding it to your environment will get you the exact same version as you're already using for your git hook at no additional storage cost - if you are already using a linter at the CLI, and you add a git hook for it, your hook will run with the exact same version that you are already using at the CLI at no additional storage cost - your configuration interface is isomorphic to the upstream one, so - any custom hooks you're already using can be added without modification beyond converting from one format to another; - any online documentation you find about adding a custom hook not distributed with the upstream framework still applies; - and you can configure new, custom, or modified hooks with a familiar interface. - any hook you write as a script or with substantial logic can also be plugged into a built-in task runner for use outside git hook contexts, where - you can express dependency relationships between tasks, so - every task runs concurrently unless dependency relations mandate otherwise. Which imo solves that problem pretty well. My team uses that kind of setup in all of our projects. > 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. I'm curious about what this means. Could you expand on it? You might be interested in something like `treefmt`, which is designed around a standard interface for configuring formatters to run in parallel, but doesn't do any package management or installation at all: https://github.com/numtide/treefmt https://github.com/numtide/treefmt (That might address both of the issues I've replied to you about so far, to some extent.) > It also uses a bunch of rando open source repos which is a supply chain nightmare even with pinning. If the linters you're running are open source, isn't this what you're ultimately doing anyway? Nix gives a bit more control here, but I'm not sure whether it directly addresses your concern. > I am working on a competing tool Oh, dammit. Only after writing all of this out did I realize you're the author of mise. I'm sure you're well aware of Nix and Devenv. :) Because I think your critiques make sense and might be shared by others, I'll post this comment anyway. I'm still interested in your replies, and your opinion of having some environment management tool plug into prek and supplant its software installation mechanisms. And because I think mise likely gets many of these things right in the same way Devenv does, and reasonable people could prefer either, I'll include links to both Devenv and mise below: https://devenv.sh/ https://devenv.sh/ https://mise.jdx.dev/ https://mise.jdx.dev/
aaronblohowiak 8mo ago
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…
timhh 8mo ago
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 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!
- jdxcode 8mo ago
  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.
  - timhh 8mo ago
    > the second the hooks modify the code they've broken your sandbox Changes to code would obviously need to be reviewed before they are committed. That's still much better than with pre-commit, where e.g. to do simple things like banning tabs you pretty much give some guy you don't know full access to your machine. Even worse - almost everyone that uses pre-commit also uses tags instead of commit hashes so the hook can be modified retroactively. One interesting attack would be for a hook to modify e.g. `.vscode/settings.json`... I should probably make the default config exclude those files. Is that what you meant? Even without that it's a lot more secure than pre-commit.
    - jdxcode 8mo ago
      You will execute code before you commit it. Maybe not always, but often enough. You will also have lints on things like build scripts. I agree it’s better, but not because of wasi
anentropic 8mo ago
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.
- OJFord 8mo ago
  I believe that was the main reason it was created - pre-commit author acknowledged the request for such support but said they wouldn't do (or merge) it in pre-commit.
__mharrison__ 8mo ago
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.
xyzzy_plugh 8mo ago
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.
- nitnelave 8mo ago
  Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing. Now, if the server enforces checks on push, that's a project policy that should be respected.
  - sa46 8mo ago
    The problem is that pre-commit hooks are much slower with a much higher false-positive rate than type checking. Pre-commit checks should be opt-in with CI as the gate. It's useful to be able to commit code in a failing state.
    - chippiewill 8mo ago
      No one forces you to install the pre-commit hook on your local checkout so what you're suggesting is universally the case. You're perfectly free to just run it manually or let it fail in CI or use `--no-verify` when committing to skip the hook if you install it.
- chuckadams 8mo ago
  I use exactly one such hook, and that's to add commit signoff because of a checklist-compliance item called DCO that fails all PRs unless they have the sign-off trailer added by `git commit -s`. I've long argued that we should be enforcing actual signed commits instead, but compliance has never been about doing the sensible thing. It's as simple as a script with a cp command that I run after any clone of a repo that requires it; certainly doesn't require anything as elaborate as a hook manager.
iFire 8mo ago
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.
semiinfinitely 8mo ago
I always just disable pre-commit
- deleted 8mo ago
  [deleted]
dpc_01234 8mo ago
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%3Az2tDzYbAXxTQEKTGFVwiJPajkbeDU 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.
- digdugdirk 8mo ago
  That looks really cool! I've been looking for a more thought-out approach to hooks on JJ, I'll dig into this. Do you have any other higher level architecture/overview documentation other than what is in that repo? It has a sense of "you should already know what this does" from the documentation as is. Also, how do you like Radicle?
  - dpc_01234 8mo ago
    > Do you have any other higher level architecture/overview documentation other than what is in that repo? SelfCI is _very_ minimal by design. There isn't really all that much to document other than what is described in the README. > Also, how do you like Radicle? I enjoy that it's p2p, and it works for me in this respect. Personally I disagree with it attempt to duplicate other features of GitHub-like forge, instead of the original collaborate model of Linux kernel that git was built for. I think it should try to replicate something more like SourceHut, mailinglist thread, communication that includes patches, etc. But I did not really _collaborated_ much using Radicle yet, I just push and pull stuff from it and it works for that just fine.
- paddy_m 8mo ago
  That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type. Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was pointed at, if tests start passing, you probably never need to revisit the failure. I want to know about local test failures before I push to remote with full CI. automatic branching and workflow stuff is optional. the core idea is great.
egorfine 8mo ago
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?
- fishgoesblub 8mo ago
  To entice people who are fluent in said language, or those who are looking for something compiled and performant. If I see a project written in (java|type)script, I know to avoid it.
- deleted 8mo ago
  [deleted]
- wtetzner 8mo ago
  Because this is Hacker News, not a marketing website. People may not only be interested in the tool itself, but also in the implementation.
fuddle 8mo ago
It would be great to see some charts on https://prek.j178.dev/benchmark/ https://prek.j178.dev/benchmark/
teaearlgraycold 8mo ago
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.
- bradleyy 8mo ago
  I leave unstaged files all the time, not sure what you mean.
  - teaearlgraycold 8mo ago
    Without extra shenanigans if you have an unstaged file that fails your test suite then pre-commit will reject your commit even if the staged files are error free.
    - bradleyy 8mo ago
      Our stuff is configured to only run on staged files.
- tomjakubowski 8mo ago
  > they … aren’t compatible with commits that leave unstaged files in your tree. It's a little surprising that git doesn't pass pre-commit hooks any information, like a list of which files were changed in the soon-to-be-made commit. git does so for pre-push, where it writes to a hook's stdin some information about the refs and remotes involved in the push. I wonder if many pre-commit hooks, like the kind which run formatters, would be better off as `clean` filters, which run on files when they are staged. The filter mechanism makes it easier to apply just to the files which were changed. In the git docs, they even use a formatter (`indent`) as an example. https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes#filters_b https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attribute...
nsm 8mo ago
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?
- Marsymars 8mo ago
  > Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following? I can't, because the point of our pre-commit use isn't to run logic in hooks that can't be run otherwise. e.g. We use pre-commit to enforce that our language's whitespace formatting has been applied. This has the same configuration in the IDE, but sometimes devs ignore IDE warnings or just open files in a text editor for a quick edit and don't see IDE warnings or w/e. "Replaced by CI" isn't really meaningful in our context - pre-commit is just a tool that runs as part of CI - some things get done as pre-commit hooks because they're fast and it's a convenient place to put them. Devs are encouraged to also run pre-commit locally, but there's no enforcement of this. > 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? We have performance metrics for pre-commit hooks and pre-push hooks. I forget the exact numbers, but we want stuff to "feel" fast, so e.g. if you're rebasing something locally with a few dozen commits it should only take seconds. Pre-push hooks have a bit more latitude.
- acdha 8mo ago
  It’s a question of feedback time and consistency: e.g. if you run Prettier/Ruff in CI, someone has to wait minutes rather than milliseconds and you either have to fix build failures or grant your CI system commit privileges and deal with merge conflicts. This also means more total CI runner usage while someone’s laptop probably has 10 idle cores. If it’s on a pull/merge request, you’re wasting reviewer time. If the hook is blocking secrets, you can’t un-push it with 100% certainty so you have to revoke credentials. For texts, I tend to have the equivalent of “pytest tests/unit/“ since those are fast and a good sanity check, especially for things like refactoring. I also run our pre-commit checks in CI for consistency so we’re never relying on someone’s local environment (web editors exist) and to keep everyone honest about their environment.
evetools 8mo ago
Anyone using on very big projects can vouch for the speed of things?
thayne 8mo ago
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.
- fortuitous-frog 8mo ago
  The author of pre-commit is known to be pretty hostile :p You should make an issue for prek though!
h4kunamata 8mo ago
"...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!!
BeeOnRope 8mo ago
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 https://github.com/pre-commit/pre-commit/issues/860 and also linked duplicates (some of which are not duplicates).
WolfeReader 8mo ago
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.
- sgarland 8mo ago
  That’s what --no-verify is for.
ChatGPTBanger 8mo ago
[dead]
flowingfocus 8mo ago
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-changelogs-and-secretspec-040/#module-changelogs https://devenv.sh/blog/2025/11/26/devenv-111-module-changelo...
- nylonstrung 8mo ago
  devenv is great!
wd40advocate 8mo ago
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.
marxisttemp 8mo ago
Emojis as bullet points in the README make me think this was generated with an LLM. No thanks
drewbitt 8mo ago
Would need auto-fix & commit capabilities to really replace lefthook or lint-staged for me. https://github.com/j178/prek/issues/1051 https://github.com/j178/prek/issues/1051

BewareTheYiga 8mo ago

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

rurban 8mo ago

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

verdverm 8mo ago
[flagged]

candiddevmike 8mo ago

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?

esafak 8mo ago
The value is in finding out something is going to fail locally before pushing it. Useful for agents and humans alike.
szenrom 8mo ago
I tend to work the other way around - what is defined in CI steps gets added to pre-commit. Several tools have already existing configurations or you can use local mode. Sure, I can't force people to use it but it saves them time as CI would fail anyway.
thoughtpalette 8mo ago
You can obviously bypass them, but having precommit hooks to run scripts locally, to make sure certain checks pass, can save them from failing in your pipeline, which can save time and money. From an org standpoint you can have them (mandate?) as part of the developer experience. (Our team doesn't use them, but I can see the potential value)
- lukasgraf 8mo ago
  I never understood this argument. The checks in those pre-commit hooks would need to be very fast - otherwise they'd be too slow to run on every commit. Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail. But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There I can see what gets changed, and react to it. Pre-commit hooks sit in such a weird place between where I author my code (editor) and the last line of defense (CI).
  - Marsymars 8mo ago
    > Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail. That's still multiple minutes compared to an error thrown on push - i.e. long enough for the dev in question to create a PR, start another task, and then leave the PR open with CI failures for days afterwards. > But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There are substantial chunk of fast checks that can't be configured in <arbitrary editor> or that require a disproportionate time investment. (e.g. you could write and maintain a Visual Studio extension vs just adding a line to grep for pre-commit)
throw20251220 8mo ago
I like my pre-receive hooks.
forgotpwd16 8mo ago
Besides during commit, pre-commit/prek can run all hooks with `run`. So in CI/CD you can replace all discrete lint/format tool calls with one to pre-commit/prek. E.g. https://github.com/python/cpython/blob/main/.github/workflows/lint.yml https://github.com/python/cpython/blob/main/.github/workflow....
- candiddevmike 8mo ago
  This just seems like calling a shell script with extra steps. I have a shell utility similar to make that CI/CD calls for each step (like for step build, run make build) that abstracts stuff. I'd have Prek call this tool, I guess, but then I don't get what benefit there is here.
fortuitous-frog 8mo ago
They're very commonly used in CI. There are dedicated GitHub actions for pre-commit and prek, but most commonly people just invoke something like `prek run --all-files` or `pre-commit run --all-files` in their typical lint CI jobs. The prek documentation has a list of many large projects (such as CPython and FastAPI, to name a few) who use it; each link is a PR of how they integrated it into CI if you want to see more: https://prek.j178.dev/#who-is-using-prek https://prek.j178.dev/#who-is-using-prek
BeeOnRope 8mo ago
They integrate well with CI. You run the same hooks in CI as locally so it's DRY and pushes people to use the hooks locally to get the early feedback instead of failing in CI. Hooks without CI are less useful since they will be constantly broken.
- candiddevmike 8mo ago
  Why wouldn't I just call the same shell script in CI and locally though? What's the benefit here? All I'm seeing is circular logic.
  - aniforprez 8mo ago
    The point is enforcement. If there's a newcomer to developing your repo, you can ask them to install the hooks and from thereon everything they commit will be compatible with the processes in your CI. You don't need to manually run the scripts they'll run automatically as part of the commit or push or whatever process
  - esafak 8mo ago
    Yes, you can run the CI script locally so you detect errors faster.
  - Marsymars 8mo ago
    pre-commit provides a convenient way to organize running a collection of shell scripts.
  - BeeOnRope 8mo ago
    If you had a shell script hook, yes you would also run that in CI. Are you asking what advantage pre-commit has over a shell script? Mostly just functionality: running multiple hooks, running them in parallel, deciding which hooks to run based on the commit files, "decoding" the commit to a list of files, offering a bunch canned hooks, offering the ability to write and install non-shell hooks in a standard way.
  - chippiewill 8mo ago
    The pre-commit tool (which prek is based on) has a large ecosystem of off the shelf checks for various language linters and other checks and a convenient way of writing them (including working out which files have changed and which checks to run based off of that) The benefit to many of having them as a hook is that you discover it's broken before you pushed your changes, and not when you finally get around to checking the CI on your branch and realising it failed after 30s. There is of course no reason why you have to have it installed as a precommit hook - many people prefer to run it manually, and the pre-commit tool/prek allows for that.
JoshTriplett 8mo ago
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.
- esafak 8mo ago
  Run the light ones on commit, the heavy ones on push.
- fortuitous-frog 8mo ago
  There's a config option for that :) https://prek.j178.dev/configuration/#default_install_hook_types https://prek.j178.dev/configuration/#default_install_hook_ty...
- anttihaapala 8mo ago
  formatting should definitely be in pre-commit though, otherwise you'll destroy diffs.
- Marsymars 8mo ago
  "pre-commit the tool" supports the pre-push hook (as well as the various other hooks).
schindlabua 8mo ago
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.
- esafak 8mo ago
  You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.
  - schindlabua 8mo ago
    I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits. Slow hooks are also not a problem in projects I manage as I don't use them.
    - esafak 8mo ago
      No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge. > Slow hooks are also not a problem in projects I manage as I don't use them. You bypass the slow hooks you mentioned? Why even have hooks then?
      - schindlabua 8mo ago
        I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.
        deleted 8mo ago
        [deleted]
      - 8mo ago
pxc 8mo ago
I think of Git hooks as a useful guiderail for myself that I share with others. They sometimes help me reduce the length of iteration cycles for workflows (which I generally don't like) where one typically commits before running/deploying (e.g., most of my team's Terraform repos). > you can't force folks to run them I think it's useful to be able to disable things like this when debugging or reconfiguring them. I sometimes disable the ones I've set up for myself, then reenable them later. > Why not just call a shell script directly? Because it's manual; I have to remember to do it each time. But there's no reason not to have a script you can invoke in other ways, if that's something you want. > How would you use these with a CI/CD platform? The thing that sets up your environment also installs the git hooks configuration, and/or you can have it invoke specific hooks via CLI.

fishgoesblub 8mo ago

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.

worldsayshi 8mo ago
I've used pre-commit very sparingly but it has happened and I also have no idea why this project need to exist? Why would pre-commit ever lead to performance problems? I get that the processes that are hooked in can be long running but the pre-commit itself? Why would it take any time at all?
globular-toast 8mo ago
Never had a problem. It adds negligible time to each commit and I have several hooks in use. Running tests takes several orders of magnitude more time.
chippiewill 8mo ago
It depends on the hooks you're using and how many of them. For some languages there are some rather slow hooks, and using it on a big monorepo can take a while (a full run across my work's main repo takes minutes). If you update python based hooks all the time then installing and creating the virtualenvs can be slow too which prek speeds up.
epage 8mo ago
For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.

deleted 8mo ago

[deleted]

esafak 8mo ago

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

aniforprez 8mo ago
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
sangeeth96 8mo ago
Love mise, didn't know about hk. Will check this out but don't think $WORK (or me) needs more than lefthook at the moment, which we're quite happy with. Wonder if there are comparisons/example projects that showcases the unique value propositions.
- aniforprez 8mo ago
  Correct me if I'm wrong but lefthook doesn't run its hooks exclusively on the staged changes IIRC. pre-commit, and prek by extension, have a process to stash the unstaged changes using git and running the code only on the staged files. Last I used it, lefthook ran on every file regardless of git status. This annoyed me because I'd have a few stray files that were not ready to be checked in or tracked that would trigger failures in lefthook. At the time this also made some hooks run slower since it would run on every single file but I think most linters have become significantly faster now.
  - mm263 8mo ago
    Please look at the example that is literally on the front page of the lefthook website: https://lefthook.dev/ https://lefthook.dev/
    - 8mo ago

jdxcode 8mo ago

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.

jayd16 8mo ago
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.
pxc 8mo ago
> My main critique is that it mixes tool installation with linting If you use a tool like this via Devenv instead of using its built-in mechanisms for installing tools: - you can add a linter without putting it on your path - you can put a linter on your path without enabling any git hooks for it - if you are already using a linter in a git hook, adding it to your environment will get you the exact same version as you're already using for your git hook at no additional storage cost - if you are already using a linter at the CLI, and you add a git hook for it, your hook will run with the exact same version that you are already using at the CLI at no additional storage cost - your configuration interface is isomorphic to the upstream one, so - any custom hooks you're already using can be added without modification beyond converting from one format to another; - any online documentation you find about adding a custom hook not distributed with the upstream framework still applies; - and you can configure new, custom, or modified hooks with a familiar interface. - any hook you write as a script or with substantial logic can also be plugged into a built-in task runner for use outside git hook contexts, where - you can express dependency relationships between tasks, so - every task runs concurrently unless dependency relations mandate otherwise. Which imo solves that problem pretty well. My team uses that kind of setup in all of our projects. > 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. I'm curious about what this means. Could you expand on it? You might be interested in something like `treefmt`, which is designed around a standard interface for configuring formatters to run in parallel, but doesn't do any package management or installation at all: https://github.com/numtide/treefmt https://github.com/numtide/treefmt (That might address both of the issues I've replied to you about so far, to some extent.) > It also uses a bunch of rando open source repos which is a supply chain nightmare even with pinning. If the linters you're running are open source, isn't this what you're ultimately doing anyway? Nix gives a bit more control here, but I'm not sure whether it directly addresses your concern. > I am working on a competing tool Oh, dammit. Only after writing all of this out did I realize you're the author of mise. I'm sure you're well aware of Nix and Devenv. :) Because I think your critiques make sense and might be shared by others, I'll post this comment anyway. I'm still interested in your replies, and your opinion of having some environment management tool plug into prek and supplant its software installation mechanisms. And because I think mise likely gets many of these things right in the same way Devenv does, and reasonable people could prefer either, I'll include links to both Devenv and mise below: https://devenv.sh/ https://devenv.sh/ https://mise.jdx.dev/ https://mise.jdx.dev/

aaronblohowiak 8mo ago

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…

timhh 8mo ago

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 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!

jdxcode 8mo ago
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.
- timhh 8mo ago
  > the second the hooks modify the code they've broken your sandbox Changes to code would obviously need to be reviewed before they are committed. That's still much better than with pre-commit, where e.g. to do simple things like banning tabs you pretty much give some guy you don't know full access to your machine. Even worse - almost everyone that uses pre-commit also uses tags instead of commit hashes so the hook can be modified retroactively. One interesting attack would be for a hook to modify e.g. `.vscode/settings.json`... I should probably make the default config exclude those files. Is that what you meant? Even without that it's a lot more secure than pre-commit.
  - jdxcode 8mo ago
    You will execute code before you commit it. Maybe not always, but often enough. You will also have lints on things like build scripts. I agree it’s better, but not because of wasi

anentropic 8mo ago

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.

OJFord 8mo ago
I believe that was the main reason it was created - pre-commit author acknowledged the request for such support but said they wouldn't do (or merge) it in pre-commit.

__mharrison__ 8mo ago

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.

xyzzy_plugh 8mo ago

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.

nitnelave 8mo ago
Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing. Now, if the server enforces checks on push, that's a project policy that should be respected.
- sa46 8mo ago
  The problem is that pre-commit hooks are much slower with a much higher false-positive rate than type checking. Pre-commit checks should be opt-in with CI as the gate. It's useful to be able to commit code in a failing state.
  - chippiewill 8mo ago
    No one forces you to install the pre-commit hook on your local checkout so what you're suggesting is universally the case. You're perfectly free to just run it manually or let it fail in CI or use `--no-verify` when committing to skip the hook if you install it.
chuckadams 8mo ago
I use exactly one such hook, and that's to add commit signoff because of a checklist-compliance item called DCO that fails all PRs unless they have the sign-off trailer added by `git commit -s`. I've long argued that we should be enforcing actual signed commits instead, but compliance has never been about doing the sensible thing. It's as simple as a script with a cp command that I run after any clone of a repo that requires it; certainly doesn't require anything as elaborate as a hook manager.

iFire 8mo ago

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.

semiinfinitely 8mo ago

I always just disable pre-commit

deleted 8mo ago
[deleted]

dpc_01234 8mo ago

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%3Az2tDzYbAXxTQEKTGFVwiJPajkbeDU 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.

digdugdirk 8mo ago
That looks really cool! I've been looking for a more thought-out approach to hooks on JJ, I'll dig into this. Do you have any other higher level architecture/overview documentation other than what is in that repo? It has a sense of "you should already know what this does" from the documentation as is. Also, how do you like Radicle?
- dpc_01234 8mo ago
  > Do you have any other higher level architecture/overview documentation other than what is in that repo? SelfCI is _very_ minimal by design. There isn't really all that much to document other than what is described in the README. > Also, how do you like Radicle? I enjoy that it's p2p, and it works for me in this respect. Personally I disagree with it attempt to duplicate other features of GitHub-like forge, instead of the original collaborate model of Linux kernel that git was built for. I think it should try to replicate something more like SourceHut, mailinglist thread, communication that includes patches, etc. But I did not really _collaborated_ much using Radicle yet, I just push and pull stuff from it and it works for that just fine.
paddy_m 8mo ago
That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type. Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was pointed at, if tests start passing, you probably never need to revisit the failure. I want to know about local test failures before I push to remote with full CI. automatic branching and workflow stuff is optional. the core idea is great.

egorfine 8mo ago

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?

fishgoesblub 8mo ago
To entice people who are fluent in said language, or those who are looking for something compiled and performant. If I see a project written in (java|type)script, I know to avoid it.
deleted 8mo ago
[deleted]
wtetzner 8mo ago
Because this is Hacker News, not a marketing website. People may not only be interested in the tool itself, but also in the implementation.

fuddle 8mo ago

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

teaearlgraycold 8mo ago

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.

bradleyy 8mo ago
I leave unstaged files all the time, not sure what you mean.
- teaearlgraycold 8mo ago
  Without extra shenanigans if you have an unstaged file that fails your test suite then pre-commit will reject your commit even if the staged files are error free.
  - bradleyy 8mo ago
    Our stuff is configured to only run on staged files.
tomjakubowski 8mo ago
> they … aren’t compatible with commits that leave unstaged files in your tree. It's a little surprising that git doesn't pass pre-commit hooks any information, like a list of which files were changed in the soon-to-be-made commit. git does so for pre-push, where it writes to a hook's stdin some information about the refs and remotes involved in the push. I wonder if many pre-commit hooks, like the kind which run formatters, would be better off as `clean` filters, which run on files when they are staged. The filter mechanism makes it easier to apply just to the files which were changed. In the git docs, they even use a formatter (`indent`) as an example. https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes#filters_b https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attribute...

nsm 8mo ago

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?

Marsymars 8mo ago
> Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following? I can't, because the point of our pre-commit use isn't to run logic in hooks that can't be run otherwise. e.g. We use pre-commit to enforce that our language's whitespace formatting has been applied. This has the same configuration in the IDE, but sometimes devs ignore IDE warnings or just open files in a text editor for a quick edit and don't see IDE warnings or w/e. "Replaced by CI" isn't really meaningful in our context - pre-commit is just a tool that runs as part of CI - some things get done as pre-commit hooks because they're fast and it's a convenient place to put them. Devs are encouraged to also run pre-commit locally, but there's no enforcement of this. > 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? We have performance metrics for pre-commit hooks and pre-push hooks. I forget the exact numbers, but we want stuff to "feel" fast, so e.g. if you're rebasing something locally with a few dozen commits it should only take seconds. Pre-push hooks have a bit more latitude.
acdha 8mo ago
It’s a question of feedback time and consistency: e.g. if you run Prettier/Ruff in CI, someone has to wait minutes rather than milliseconds and you either have to fix build failures or grant your CI system commit privileges and deal with merge conflicts. This also means more total CI runner usage while someone’s laptop probably has 10 idle cores. If it’s on a pull/merge request, you’re wasting reviewer time. If the hook is blocking secrets, you can’t un-push it with 100% certainty so you have to revoke credentials. For texts, I tend to have the equivalent of “pytest tests/unit/“ since those are fast and a good sanity check, especially for things like refactoring. I also run our pre-commit checks in CI for consistency so we’re never relying on someone’s local environment (web editors exist) and to keep everyone honest about their environment.

evetools 8mo ago

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

thayne 8mo ago

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.

fortuitous-frog 8mo ago
The author of pre-commit is known to be pretty hostile :p You should make an issue for prek though!

h4kunamata 8mo ago

"...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!!

BeeOnRope 8mo ago

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 https://github.com/pre-commit/pre-commit/issues/860 and also linked duplicates (some of which are not duplicates).

WolfeReader 8mo ago

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.

sgarland 8mo ago
That’s what --no-verify is for.

ChatGPTBanger 8mo ago

[dead]

flowingfocus 8mo ago

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-changelogs-and-secretspec-040/#module-changelogs https://devenv.sh/blog/2025/11/26/devenv-111-module-changelo...

nylonstrung 8mo ago
devenv is great!

wd40advocate 8mo ago

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.

marxisttemp 8mo ago

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

drewbitt 8mo ago

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