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

121–130 of 133 posts

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

#121

Post by pxc »

jdxcode wrote: post #120
pxc wrote: post #116

Earlier quoted context omitted.

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

It's idiomatic in pre-commit to leverage the public plugins which all do their own tool installation. If you're not using them, and also not using it for tool installation, I'm not sure why you'd not be using the much simpler lefthook. If you look at hk you will understand what I'm talking about in regards to parallelism. hk uses read/write locks and other techniques like processing --diff output to safely run multip…

> If you look at hk you will understand what I'm talking about in regards to parallelism. hk uses read/write locks and other techniques like processing --diff output to safely run multiple fixers in parallel without them stomping on each other. treefmt doesn't support this either, it won't let you run multiple fixers on the same file at the same time like hk will.

That sounds pretty cool! I will definitely take a closer look.

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

#122

Post by Cthulhu_ »

dpc_01234 wrote: post #43

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…

I see it as a layered system, each one slower than the last, but saving time in the long run.

* in-editor, real time linting / formatting / type checking. This handles whatever file you have open at the time.

* pre-commit, do quick checks for all affected code - linting, type checking, formatting, unit tests.

* CI server, async / slow tests. Also does all the above (because pre-commit / pre-push scripts are clientside and cannot be guaranteed to run), plus any slower checks like integration tests.

Basically "shift left", because it takes 100x as long to find and fix a typo (for example) if you find it in production compared to in your editor while writing.

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

#123

Post by jdxcode »

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

ok but I was replying to a comment about a tool which advertises precisely that feature

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

#124

Post by nickjj »

jiehong wrote: post #61
dpc_01234 wrote: post #43

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…

Yep, I think a watcher is better suited [0] to trigger on file changes. I personally can't stand my git commit command to be slow or to fail. [0]: such as https://github.com/watchexec/watchexec

> I personally can't stand my git commit command to be slow or to fail.

I feel the same way but you can have hooks run on pre-push instead of pre-commit. This way you can freely make your commits in peace and then do your cleanup once afterwards, at push time.

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

#125

Post by samuelstros »

dpc_01234 wrote: post #43

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…

Oh interesting. Checks sound similar to lix validation rules [1].

We were coming from a an application perspective where blocking the users intent is a no-go.

Do you have a link to a discussion where the JJ community is discussing checks?

[1] https://github.com/opral/lix/issues/239

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

#127

Post by wtetzner »

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?

Because this is Hacker News, not a marketing website. People may not only be interested in the tool itself, but also in the implementation.

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

#130

Post by timhh »

jdxcode wrote: post #93
timhh wrote: post #52

Earlier quoted context omitted.

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

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

It is better because of WASI. That's what provides sandboxing.
Post reply on HN