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

Just to make clear it's been written -- sorry, ENGINEERED -- in Rust.

But that's the whole point of locally checking the code, no? Would you prefer to commit broken things, fix them and then rebase and squash each time?

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.

> 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

(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://mise.jdx.dev/

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 purpose, neither of which modifies the code.

This is also, of course, a reasonable place to have people use `tofu plan`. It you want bad code to fail as quickly as possible, you can do:

tflint -> tfsec -> tofu validate -> tofu plan

That'll catch everything Terraform will let you catch before deploy time— most of it very quickly— without modifying any code.

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.

> If the linters you're running are open source, isn't this what you're ultimately doing anyway?

You have to trust the linters. You don't also need to trust the plugin authors. In hk we don't really use "plugins" but the equivalent is first-party so you're not extending trust to extra parties beyond me and the lint vendors.