zlacker

Interesting. I've been working on a pre-commit replacement too, written in Rust but using WASI for all plugins (no exceptions!). I haven't got very far but I think this will have huge advantages over pre-commit, mostly in reliability.

Me and my colleagues have had numerous issues setting up pre-commit because it inherits Python's atrocious infrastructure.

I'm curious how this is going to deal with actually running plugins? Will it take the same approach as pre-commit and add dedicated not-very-good support for a load of different languages?

>>timhh+(OP)
Not gonna say Python isn't a mess but I'm surprised a self-contained application is so bad. All the pieces are there to have it work— give it its own venv, use wrappers or the shebang so transparently uses it, and plug-ins get installed into that venv. All should be happy.

>>timhh+(OP)
Is it that difficult to use `pipx install` or `uv tool install`?

>>tralln+73
Yes. Those are both more effort and less reliable than what I am planning (a static binary with WASI plugins).

>>timhh+(OP)
You will be able to use mise to set up any tools required for the linters. See https://mise.jdx.dev/dev-tools/

>>timhh+(OP)
I also looked into WASI as well as lua until I ultimately decided that I think I can get rid of the concept of plugins altogether in favor of pkl. We'll see how well that works out but right now I don't have any use-cases that would require plugins and if I can stick to that it will definitely help performance.

>>jdxcod+zf
I don't really understand. Pkl seems to be a configuration language? How are you going to run clang-format, rustfmt, go fmt, pyright, etc. using Pkl?

>>timhh+Yj
it just needs to define shell script

>>jdxcod+Ep
So you have to already have all the linters installed? Ok I am planning to solve that problem too, but we'll have to see whether it's actually possible to compile e.g. rustfmt to WASI. In my experience so far WASI is pretty alpha quality.

>>timhh+(OP)
Pre-commit has like the worst DX to me, so I'm really looking forward to a replacement.

My biggest gripes are:

1. Pre-commit hooks are designed to modify files in-place, which turns `git commit` into something that can alter your work tree. IMO those tools should never ever modify files (unless explicitly asked by the user) and only output a diff and exit code that signifies if the check failed.

2. It manages the tools with its own environment but never exposes it. I always have to dig around its cache directory to find out which executable it is running if I have to reproduce the problem after something goes wrong.

>>timhh+ps
mise is my solution to that problem. I don't think it should be the job of a hook manager to install things developers should have installed for other reasons anyways.

>>timhh+B8
I agree to both. It just sounded to me like it is an unbearable experience, which I wanted to correct. Certainly, on a clean slate, I prefer a static binary