New package manager: Pkl

[sahidvelji]

Tell us more.

Renovate has no support for Pkl, Apple's configuration language. Pkl modules reference packages by absolute package:// URI, with the version inline:

amends "package://github.com/jdx/hk/releases/download/v1.58.1/hk@1.58.1#/Config.pkl"

Nothing updates these today — no manager, no datasource, and no existing issue or discussion I could find.

My motivation is hk, a git hooks and project lint runner configured through a Pkl file, which is where the example above comes from. It's also where the gap is most visible, because Renovate already manages half the problem: hk is first-class in the mise manager, so mise.toml stays current while the hk.pkl beside it never moves. Of the repositories I surveyed that amend a released hk package, every one is behind — two by 48 releases, in the same commit where mise.toml is current. hk alone is referenced from 846 files across 300+ public repositories.

I've implemented a pkl manager — /\.pkl$/, extracts package URIs, maps them onto github-releases, no new datasource. Unit tests at 100% coverage, pnpm check and pnpm type-check green. Since it emits the same depName/packageName as the mise manager, mise.toml and hk.pkl group into a single PR with no user configuration.

Would you take a PR for this? Three calls I'd like from you first:

1. Bare registry paths. A URI like package://pkg.pkl-lang.org/pkl-pantry/pkl.toml@1.0.3 never names a repository, so the manager has to choose a packageName to look up releases in. It infers apple/<project> — every project served under a bare path today is Apple's, and third parties use a github.com/<owner>/<repo> path instead. A wrong inference fails the lookup rather than producing a bad PR. Would you prefer an explicit allowlist of projects, or a pkl datasource that follows the registry's redirect to discover the repository?
2. Categories. None of the existing values fit a configuration language, so the docs page renders as no-category, like typst. Acceptable?
3. Scope. PklProject dependencies are excluded: updating them means regenerating PklProject.deps.json in the same commit, so Pkl would have to be added to Containerbase first. I'd suggest doing that as a follow-up rather than holding this back — does that split work for you?

New package manager questionnaire

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

Name / language: Pkl — package support built into the Pkl language and CLI. No competing package manager exists for it.

Popularity: GitHub code search over public repos, which caps result pages, so these are floors: ~10,300 .pkl files containing amends; ~1,780 files referencing package://pkg.pkl-lang.org; ~910 referencing package://github.com; 714 PklProject files. jdx/hk alone appears in 846 files across ≥302 repositories.

Package files: any .pkl module can reference packages directly. managerFilePatterns: /\.pkl$/. Users won't need to extend it — the extension is fixed by the language. Most .pkl files contain no package URIs; extractPackageFile returns null for those so they're dropped.

Parsing: files are parsed independently, no tool is invoked. Line-based matching for the clause and expression forms, then a structural split of the URI following the language reference grammar — 'package://' <host> <path> '@' <semver> ['::sha256:' <checksum>] '#' <asset path> — taking the last @, as PackageUri.java does.

Dependency types: none; all dependencies are the same.

Versioning: semver — Pkl rejects a package URI whose version isn't valid semver. No range constraints; URIs always pin an exact version.

Lookup: no new datasource, no custom host or registry configuration, no constraints to feed into lookup.

Artifacts: projects use PklProject.deps.json, which is out of scope as described above. Files matched by this manager have no lock file, so there's nothing to regenerate and no cache to control.

What is extracted, and how URIs map to lookups

Syntax	Extracted
amends "package://…" / extends "package://…"	yes
import "package://…", import* "package://…", with or without as	yes
import("package://…") / import*("package://…") expressions	yes
Commented-out clauses	no
Relative, pkl:, file:, https:, modulepath: URIs	no — no version to update
projectpackage: URIs	no — these resolve through a project

URI	packageName	notes
package://github.com/<owner>/<repo>/releases/download/<tag>/<name>@<ver>	<owner>/<repo>	extractVersion derived from how the tag wraps the version
package://pkg.pkl-lang.org/github.com/<owner>/<repo>[/<name>]@<ver>	<owner>/<repo>	registry 301s here; tag is <name>@<ver>
package://pkg.pkl-lang.org/<project>/<name>@<ver>	apple/<project>	registry 301s here
any other host	—	skipReason: 'unsupported-url'
any URI pinning ::sha256:	—	skipReason: 'unsupported'

Checksum-pinned URIs are skipped because bumping the version invalidates the pinned checksum and Renovate can't recompute it. Modelling it as a currentDigest would be the natural follow-up, given a datasource that can return the published <name>@<version>.sha256.

I verified the registry redirects rather than assuming them, for pkl-pantry, pkl-k8s, pkl-go, pkl-spring, pkl-project-commons and a third-party package. The host mapping also matches what pklr, an independent Pkl implementation, resolves these URIs to.

How I verified it

Beyond unit tests, extraction was run against real files:

Source	depName	packageName	currentValue
jdx/xx hk.pkl	hk	jdx/hk	1.48.0 (×2 — amends and import)
jdx/demand hk.pkl	hk	jdx/hk	1.19.0
jdx/mise hk.pkl	hk	jdx/hk	1.55.0
jdx/aube hk.pkl	hk	jdx/hk	1.44.3
element-hq/element-x-ios Secrets.pkl	staticcode	element-hq/pkl-tools	1.1.0
apple/pkl-pantry yaml.pkl	—	—	no package URIs, file dropped

A --platform=local dry run on a repository holding an hk.pkl pinned at 1.48.0 next to mise.toml pinning hk = "1.48.0" put all three dependencies — one from mise, two from pkl — onto a single renovate/hk-1.x branch at 1.58.1. Driving those upgrades through doAutoReplace produced:

amends "package://github.com/jdx/hk/releases/download/v1.58.1/hk@1.58.1#/Config.pkl"
import "package://github.com/jdx/hk/releases/download/v1.58.1/hk@1.58.1#/Builtins.pkl"

confirming both lines, and both occurrences of the version within each line, are updated. The version appearing twice per URI is handled by the default autoReplaceGlobalMatch.

Disclosure: this proposal and the implementation behind it were written with Claude Code (Claude Opus). I reviewed everything before posting, and will review anything posted under my name.

[sakuro]

I am happy if this is implemented in renovate itself. As a workaround, I use custom managers like this in all my repos for now.