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

51–60 of 133 posts

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

#51

Post by mm263 »

aniforprez wrote: post #50
sangeeth96 wrote: post #34

Earlier quoted context omitted.

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.

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

Please look at the example that is literally on the front page of the lefthook website: https://lefthook.dev/

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

#52

Post by timhh »

jdxcode wrote: post #27
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.

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

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

#53

Post by jdxcode »

aniforprez wrote: post #50
sangeeth96 wrote: post #34

Earlier quoted context omitted.

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.

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

in hk you can not only have a mix of staged/unstaged files but it even deals with staged/unstaged HUNKS in the same file (best it can at least)

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

#54

Post by sa46 »

nitnelave wrote: post #37
xyzzy_plugh wrote: post #29

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

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.

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.

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

#55

Post by fishgoesblub »

egorfine wrote: post #46

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?

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.

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

#57

Post by chuckadams »

xyzzy_plugh wrote: post #29

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

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.

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

#58

Post by accelbred »

jdxcode wrote: post #27
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.

I wouldn't want hooks modifying the code. They should be only approve/reject. Ideally landlock rules would give them only ro access to repo dir

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

#60

Post by aniforprez »

mm263 wrote: post #51
aniforprez wrote: post #50

Earlier quoted context omitted.

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

Please look at the example that is literally on the front page of the lefthook website: https://lefthook.dev/

Ah ok the home page actually reminded me what the actual issue was. It can pass the list of staged files to the command but since it doesn't actually stash anything, it's not compatible with commands that don't accept a list of files. golangci-lint for example doesn't accept a list of files like this and will run on every single file in the repo. I don't know if this behaviour has changed in lefthook or golangci-lint now.
Post reply on HN