What is the use case?

Following up on my #1482 (comment), I wanted to put together a more detailed proposal for switching from pre-commit to prek.

prek is a Rust-based reimagining of the pre-commit framework designed to be a drop-in replacement that's significantly faster and uses less disk space (already being used by projects like CPython, Apache Airflow, FastAPI, Ruff, etc.).

In the spirit of continuing to adopt Rust-based tooling (like we did with #1425), this feels like a natural fit for the project.

Describe the solution you'd like

I went through our current .pre-commit-config.yaml and verified that prek supports everything we're using: namely: local hooks with language support, the remote hooks from pre-commit-hooks, ruff-pre-commit, ... are config compatible. The SKIP env var we use in CI becomes PREK_SKIP but otherwise works the same way.

The migration itself should be minimal. The existing .pre-commit-config.yaml file can stay as-is since prek reads the same format. The CI workflows would need updating to use prek-action instead of installing pre-commit via pip (& the SKIP references would become PREK_SKIP as previously stated). Documentation in the contributing guide and dev setup docs would need the command names updated from pre-commit to prek.

Additional context

The one thing that changes is pre-commit.ci. Prek doesn't have an equivalent hosted service for automatic updates (yet*?), but we can handle this through Dependabot. Given we've set autoupdate_schedule: 'monthly' and autofix_prs: false, this seems like a low-friction tradeoff.

❤️ Contributors, please refer to 📙Contributing Guide.
Unless the PR can be sent immediately (e.g. just a few lines of code), we recommend you to leave a comment on the issue like I'm working on it or Can I work on this issue? to avoid duplicating work. Our Discord server is always open and friendly.