New package manager request: prek

[shaanmajid]

prek is a growing git pre-commit framework written in Rust. prek is a compatible replacement to pre-commit, using the same hook repository ecosystem and the config file (.pre-commit-config.yaml). Because of this, prek users have thus far been able to use Renovate's existing pre-commit support. Recently, however, prek began adding support for its own configuration format, prek.toml, in addition to the existing YAML format.

prek's dependency model is identical to pre-commit: repositories are pinned by repo URL + rev tag, and the goal is to keep rev values up to date. prek uses the same hook repos, same versioning (git tags), and same datasources (github-tags, gitlab-tags).

I think a standalone prek manager makes more sense than extending the existing pre-commit manager; it's a different tool and config for the same ecosystem, which is how Renovate already handles npm/yarn/pnpm and the various pip managers. Also, there has been some past conflict between Renovate and pre-commit, resulting in a disabled-by-default status. We are eager to work through some of these past friction points and work together for Renovate support :)

The shared logic (URL parsing, datasource mapping, additional_dependencies extraction) could be imported from the pre-commit manager or duplicated.

I would be more than happy to submit a PR if that would be accepted or help speed things along :) Since no new datasource or versioning is needed, this should be a single PR adding lib/modules/manager/prek/.

[github-actions[bot]]

Hi there,

You're asking us to support a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we'll decide if we want to support this new manager.

Good luck,

The Renovate team

[shaanmajid]

New package manager questionnaire

Did you read our documentation on adding a package manager?

• I've read the adding a package manager documentation.

Basics

What's the name of the package manager?

prek

What language(s) does this package manager support?

Language-agnostic: prek manages git hooks that can be written in any language. The hooks themselves are pulled from remote git repositories and pinned to specific tags.

How popular is this package manager?

prek has 6k+ stars on GitHub (as of Feb 2026). It's the primary alternative to pre-commit and is growing rapidly.

Does this language have other (competing?) package managers?

• Yes (give names).
• No.

pre-commit: Renovate already has a manager for pre-commit's .pre-commit-config.yaml format. prek is a compatible successor that uses the same hook repository ecosystem but has its own TOML-based configuration format (prek.toml). prek also supports .pre-commit-config.yaml for backward compatibility, which is handled by the existing pre-commit manager.

What are the big selling points for this package manager?

• Single static binary (no Python runtime needed, unlike pre-commit)
• Parallel hook execution
• Compatible with the entire pre-commit hook ecosystem
• First-class monorepo support via workspace mode (multiple prek.toml files in subdirectories)

Detecting package files

What kind of package files, and names, does this package manager use?

prek.toml: a TOML configuration file at the repository root (or in subdirectories for monorepo/workspace setups).

Which managerFilePatterns pattern(s) should Renovate use?

"managerFilePatterns": ["/(^|/)prek\\.toml$/"]

Do many users need to extend the managerFilePatterns pattern for custom file names?

• Yes, provide details.
• No.

Is the managerFilePatterns pattern going to get many "false hits" for files that have nothing to do with package management?

No. prek.toml is a specific filename referencing and used exclusively by prek.

Parsing and Extraction

Can package files have "local" links to each other that need to be resolved?

No.

Package file parsing method

The package files should be:

• Parsed together (in serial).
• Parsed independently.

Which format/syntax does the package file use?

• JSON
• TOML
• YAML
• Custom (explain below)

How should we parse the package files?

• Off the shelf parser.
• Using regex.
• Custom-parsed line by line.
• Other.

Standard TOML parser should suffice here.

Does the package file have different "types" of dependencies?

• Yes, production and development dependencies.
• No, all dependencies are treated the same.

List all the sources/syntaxes of dependencies that can be extracted

1. Remote repository (primary)

[[repos]]
repo = "https://github.com/astral-sh/ruff-pre-commit"
rev = "v0.15.0"
hooks = [
    { id = "ruff-check", args = ["--fix"] },
    { id = "ruff-format" },
]

[[repos]]
repo = "https://github.com/astral-sh/uv-pre-commit"
rev = "0.10.2"
hooks = [
    { id = "uv-lock" },
]

repo is a git URL (HTTPS, SSH, or git protocol). rev is a git tag or commit SHA.

Supported URL formats:

• https://github.com/owner/repo
• https://gitlab.com/owner/repo
• git@github.com:owner/repo
• git://github.com/owner/repo
• ssh://git@github.com/owner/repo

2. Additional dependencies (secondary)

Hooks can declare additional_dependencies with an explicit language:

[[repos.hooks]]
id = "mypy"
language = "python"
additional_dependencies = ["types-requests==2.31.0"]

The dependency format is language-specific (PEP 508 for python, npm name@range for node, Go module paths for golang). These are identical in semantics to pre-commit's additional_dependencies.

Describe which types of dependencies above are supported and which will be implemented in future

The initial implementation should support remote repository extraction (type 1): parsing repo URLs and rev tags. This is the core use case and covers the vast majority of prek.toml files.

Additional dependencies (type 2) can be added with initial support or as follow-up work. The semantics and formats are identical to the existing pre-commit manager's additional_dependencies handling (node/python/golang), so the same extraction logic applies.

Versioning

What versioning scheme does the package file(s) use?

Git tags. The rev field contains a git tag (e.g., v5.0.0, v0.8.4) or a commit SHA. This is the same scheme used by the existing pre-commit manager.

Does this versioning scheme support range constraints, like ^1.0.0 or 1.x?

• Supports range constraints (for example: ^1.0.0 or 1.x), provide details.
• No.

Lookup

Is a new datasource required?

• Yes, provide details.
• No.

Reuses github-tags and gitlab-tags, same as the existing pre-commit manager.

Will users want (or need to) set a custom host or custom registry for Renovate's lookup?

• Yes, provide details.
• No.

Same as pre-commit: users with self-hosted GitHub Enterprise or GitLab instances will need hostRules to map custom hostnames to the appropriate datasource. The existing determineDatasou rce() logic in the pre-commit manager handles this already.

Where can Renovate find the custom host/registry?

• No custom host or registry is needed.
• In the package file(s), provide details.
• In some other file inside the repository, provide details.
• User needs to configure Renovate where to find the information, provide details.

The hostname is embedded in the repo URL (e.g., https://gitlab.mycompany.com/team/hooks). The existing pre-commit manager's URL-parsing and hostRules lookup logic handles this.

Are there any constraints in the package files that Renovate should use in the lookup procedure?

• Yes, there are constraints on the parent language (for example: supports only Python v3.x), provide details.
• Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details.
• Yes, some other kind of constraint, provide details.
• No constraints.

Will users need the ability to configure language or other constraints using Renovate config?

• Yes, provide details.
• No.

Artifacts

Does the package manager use a lock file or checksum file?

• Yes, uses lock file.
• Yes, uses checksum file.
• Yes, uses lock file and checksum file.
• No lock file or checksum.

Is the locksum or checksum mandatory?

• Yes, locksum is mandatory.
• Yes, checksum is mandatory.
• Yes, lock file and checksum are mandatory.
• No mandatory locksum or checksum.
• Package manager does not use locksums or checksums.

If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file?

N/A

Package manager cache

Does the package manager use a cache?

• Yes, provide details.
• No.

prek caches cloned hook repositories, hook environments, and language toolchains in $PREK_HOME (defaults to the platform's XDG cache directory, e.g. ~/.cache/prek/ on Unix/POSIX-compliant systems).

If the package manager uses a cache, how can Renovate control the cache?

• Package manager does not use a cache.
• Controlled via command line interface, provide details.
• Controlled via environment variables, provide details.

The PREK_HOME environment variable controls the cache directory, and prek cache clean clears it.

Should Renovate keep a cache?

• Yes, ignore/disable the cache.
• No.

The cache lives entirely outside the repository and is not relevant to Renovate; Renovate only needs to edit rev values in prek.toml and I don't think needs to invoke prek itself.

Generating a lockfile from scratch

Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch.
Can the package manager generate a lockfile from scratch?

• Yes, explain which command Renovate should use to generate the lockfile.
• No, the package manager does not generate a lockfile from scratch.
• No, the package manager does not use lockfiles.

Other

What else should we know about this package manager?

1. Scope: prek also reads .pre-commit-config.yaml for backward compatibility, which is already handled by Renovate's existing pre-commit manager. This proposal covers only prek.toml. Users with YAML configs can enable the pre-commit manager alongside the prek manager; the two target different files and will not conflict.

2. minimum_prek_version field: prek.toml supports a minimum_prek_version field (top-level and per-hook). This is not a dependency. it's a compatibility floor. Renovate should not bump this field by default, but it may be desirable by some users. (This was a source of friction with pre-commit, see Pre-commit minimum version and docker entry #11166)

3. Code reuse: The extraction logic (URL parsing, datasource determination) is functionally identical to the existing pre-commit manager and can be imported or duplicated.

[shaanmajid]

Hi! The questionnaire has been filled out for a couple of weeks now. I'm happy to submit a PR if this looks like something the team would accept. Just want to confirm before investing the effort. Thanks!

[jamietanna]

Hey, sorry yes we are happy to add it! @RahulGautamSingh would you mind doing a quick check to confirm that the questionnaire tracks with the support?

Happy for you to start working on a PR in the meantime

[RahulGautamSingh]

LGTM Issue created: #41683