Add @girs dependency auto-update workflow#135
Conversation
Keep the @girs/* type dependencies on the latest stable release without manual bumps. - scripts/update-girs.mjs pins every @Girs dependency to its npm "latest" dist-tag as an exact version. Exact pins are required: the @Girs scheme encodes the library and ts-for-gir version in one semver string, so a stable suffix sorts below a release candidate and ranges resolve back to the rc (see #125). The script leaves protocol specifiers like "workspace:" untouched and does not rename packages. - "yarn update:girs" runs it for the package and the example. - .github/workflows/update-girs.yml runs daily (plus manual dispatch and a repository_dispatch "girs-release" hook), bumps, installs, validates, and opens/updates a single chore/update-girs PR only when something changed — as a draft with a warning if validation fails.
There was a problem hiding this comment.
Nice flow! LGTM
Personally, I would adapt the schedule to run once a week (instead of daily). But thats just personal preference, resulting from experience with renovate which tends to open new PRs on a daily basis if it isn't restricted in that kind of way (and this also helps mitigating the supply-chain attacks [up to a point] that became so popular recently). Probably non of that is relevant for this workflow.
@girs/cogl-2.0 pulled a second, incompatible copy of the Cogl types into the tree, so a method using both Cairo and Cogl types could not type-check. @girs/cogl-18 is the version @girs/clutter-18 and @girs/meta-18 depend on; switching to it dedupes Cogl and lets Cairo + Cogl be used together. Leaves the @Girs versioning scheme untouched (still on the current rc ranges) so the auto-update workflow in #135 can take over the bumps. Closes #126
Address review on #135: - Schedule weekly (Mon 06:00 UTC) instead of daily, per @schnz — avoids renovate-style daily PR churn and slightly reduces supply-chain exposure window. - Drop NODE_OPTIONS=--max_old_space_size=9216 from the validate steps; build:types + validate:types/example pass under Node 22's default heap (verified locally), so the 9 GiB override isn't needed.
ts-for-gir#432 (released as 4.1) drops the coupled <lib>-<app> version scheme: @Girs packages now version as the ts-for-gir release alone, so a caret range dedupes across stable releases and excludes prereleases (on Yarn 4 too). Switch the updater from exact pins to `^<latest>` and rewrite the now-obsolete rationale (script header + PR-body text). Exact top-level pins are avoided on purpose: they re-diverge from the transitive `^x` deps as soon as a newer @Girs patch ships, re-opening the duplicate-copy issue (ts-for-gir#431). Verified locally: emits `^4.1.0`, is idempotent (no-op second run, so no PR churn), and leaves `workspace:` specifiers untouched.
|
One more change beyond the review points, worth flagging since your approval predates it: I switched the updater from exact pins to caret ranges ( Rationale: ts-for-gir#432 (released as 4.1) dropped the coupled Verified locally: emits |
Yes, I saw that change. Nice to have semver-compatible versions now :) |
2 participants
Automates keeping the
@girs/*type dependencies current, so we don't have to bump them by hand after every ts-for-gir release.How it works
workflow_dispatch+ agirs-releaserepository_dispatchfor an instant trigger from ts-for-gir's release workflow.scripts/update-girs.mjsbumps every@girs/*dep to^<latest>(caret on the npmlatestdist-tag). The workflow then installs, runs the full validation (build:types,prettier:check,validate:types,build:example,validate:example) and opens/updates a PR — as a draft if validation fails, so type-affecting upgrades are flagged rather than merged blindly.Why caret ranges
Since gjsify/ts-for-gir#432 (released as 4.1)
@girs/*versions as the ts-for-gir release alone (release-only scheme). On that scheme a caret range dedupes across stable releases and excludes prereleases (4.2.0-rc.1does not satisfy^4.1.0) — on Yarn 4 too.Exact top-level pins are deliberately avoided: they re-diverge from the transitive
^xdeps of the@girspackages as soon as a newer@girspatch ships, which re-opens the duplicate-copy issue (ts-for-gir#431). The updater therefore advances the caret floor to the latest release — this refreshes the declared minimum and gives the workflow a concrete diff to validate the new types against.Verified locally: emits
^4.1.0, is idempotent (no-op on a second run, so no PR churn), and leavesworkspace:specifiers untouched.The namespace fix (
@girs/cogl-2.0→@girs/cogl-18, #126 / #132) stays manual — the script only bumps versions of existing keys, it doesn't add/remove/rename packages. The first scheduled run will bump the deps off the release candidates, addressing #125.