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

Post by timhh » Wed, Feb 04, 2026, 10:28 PM UTC

accelbred wrote: post #58

jdxcode wrote: post #27

Earlier quoted context omitted.

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

Post by sgarland » Thu, Feb 05, 2026, 5:46 PM UTC

pxc wrote: post #118

sgarland wrote: post #98

Earlier quoted context omitted.

It depends. I wrote a pre-commit hook (in shell, not precommit the tool) at a previous job that ran terraform fmt on any staged files (and add the changes to the commit) because I was really tired of having people push commits that would then fail for trivial things. It was overrideable with an env var. IMO if there’s a formatting issue, and the tool knows how it should look, it should fix it for you.

The standard way for this with current tools is to have the formatter/linter make the changes but exit with a non-zero status, failing the hook. Then the person reviews the changes, stages, and commits. (That's what our setup currently has `tofu fmt` do.) But if you don't want to have hooks modify code, in a case like this you can also just use `tofu validate`. Our setup does `tflint` and `tofu validate` for this pur…