|
| 1 | +--- |
| 2 | +title: Renovate |
| 3 | +--- |
| 4 | + |
| 5 | +import Tabs from '@theme/Tabs'; |
| 6 | +import TabItem from '@theme/TabItem'; |
| 7 | + |
| 8 | +[Renovate](https://docs.renovatebot.com/) automates dependency updates by opening pull requests when |
| 9 | +new versions are released. Because moon builds on [proto](../proto) for toolchain management, and |
| 10 | +proto is supported by Renovate out of the box, most moon repositories work with Renovate with little |
| 11 | +to no configuration. This guide covers that native support, and how to extend it to versions pinned |
| 12 | +in moon's own configuration files. |
| 13 | + |
| 14 | +## Pin versions in `.prototools` (recommended) |
| 15 | + |
| 16 | +The cleanest setup requires **no Renovate configuration and no annotations at all**. Renovate ships a |
| 17 | +built-in [`proto` manager](https://docs.renovatebot.com/modules/manager/proto/) that updates tool |
| 18 | +versions declared in [`.prototools`](../proto/config) files automatically. |
| 19 | + |
| 20 | +```toml title=".prototools" |
| 21 | +node = "22.18.0" |
| 22 | +yarn = "4.16.0" |
| 23 | +rust = "1.85.0" |
| 24 | +moon = "2.4.2" |
| 25 | +``` |
| 26 | + |
| 27 | +Because moon toolchains inherit their version from `.prototools` by default (via |
| 28 | +[`versionFromPrototools`](../config/toolchain#versionfromprototools)), you can leave the `version` |
| 29 | +out of [`.moon/toolchains.yml`](../config/toolchain) entirely and let proto be the single source of |
| 30 | +truth: |
| 31 | + |
| 32 | +```yaml title=".moon/toolchains.yml" |
| 33 | +# No version here — inherited from .prototools |
| 34 | +node: {} |
| 35 | +rust: {} |
| 36 | +``` |
| 37 | +
|
| 38 | +With this approach, Renovate keeps `.prototools` current, moon resolves toolchains from it, and |
| 39 | +derived fields (like `package.json`'s `packageManager`) stay in sync — no `# renovate:` comments |
| 40 | +required. |
| 41 | + |
| 42 | +:::tip |
| 43 | + |
| 44 | +If you can, prefer this over hard-coding a `version` in `.moon/toolchains.yml`. It's the least |
| 45 | +configuration, and nothing drifts out of sync. |
| 46 | + |
| 47 | +::: |
| 48 | + |
| 49 | +## Versions in moon configuration |
| 50 | + |
| 51 | +If you'd rather pin versions in moon's config files — or you have versions that don't live in |
| 52 | +`.prototools` at all (the moon [`versionConstraint`](../config/workspace#versionconstraint), a CI |
| 53 | +input, a WASM plugin) — moon publishes a shared Renovate |
| 54 | +[config preset](https://docs.renovatebot.com/config-presets/) to cover them. |
| 55 | + |
| 56 | +<Tabs groupId="renovate-setup"> |
| 57 | +<TabItem value="preset" label="Extend the preset (recommended)"> |
| 58 | + |
| 59 | +```json title="renovate.json" |
| 60 | +{ |
| 61 | + "$schema": "https://docs.renovatebot.com/renovate-schema.json", |
| 62 | + "extends": ["config:recommended", "github>moonrepo/moon//ecosystem/renovate"] |
| 63 | +} |
| 64 | +``` |
| 65 | + |
| 66 | +</TabItem> |
| 67 | +<TabItem value="inline" label="Inline configuration"> |
| 68 | + |
| 69 | +If you'd rather not depend on the preset, copy its |
| 70 | +[custom managers](https://docs.renovatebot.com/modules/manager/custom/) directly into your |
| 71 | +configuration — see the source at |
| 72 | +[`ecosystem/renovate.json`](https://github.com/moonrepo/moon/blob/master/ecosystem/renovate.json). |
| 73 | + |
| 74 | +</TabItem> |
| 75 | +</Tabs> |
| 76 | + |
| 77 | +### Toolchain versions (no annotations) |
| 78 | + |
| 79 | +The preset includes [JSONata managers](https://docs.renovatebot.com/modules/manager/jsonata/) that |
| 80 | +read your [`toolchains`](../config/toolchain) config _by structure_, so a `version` pinned for a |
| 81 | +built-in toolchain is updated automatically — **no comments needed**. This works for the `yml`, |
| 82 | +`yaml`, `json`, and `toml` formats (in `.moon/` or `.config/moon/`): |
| 83 | + |
| 84 | +```yaml title=".moon/toolchains.yml" |
| 85 | +node: |
| 86 | + version: '22.18.0' |
| 87 | +rust: |
| 88 | + version: '1.85.0' |
| 89 | +``` |
| 90 | + |
| 91 | +### Other versions |
| 92 | + |
| 93 | +For anything the structural managers don't cover, the preset also includes a regex manager that reads |
| 94 | +a trailing `# renovate:` (or `// renovate:`) comment. Add it to the _end of the line_ containing the |
| 95 | +version, and point it at a [datasource](https://docs.renovatebot.com/modules/datasource/) and package. |
| 96 | +It applies to `.moon/` (and `.config/moon/`) configs, `moon.*` project files, and |
| 97 | +`.github/workflows/*.yml`, in any comment-supporting format (`yml`, `yaml`, `toml`, `jsonc`, `pkl`, |
| 98 | +`hcl` — strict `json` has no comments): |
| 99 | + |
| 100 | +```yaml title=".moon/workspace.yml" |
| 101 | +# Pin the version of moon itself |
| 102 | +versionConstraint: '>=2.4.2' # renovate: datasource=github-releases depName=moonrepo/moon extractVersion=^v(?<version>.*)$ |
| 103 | +``` |
| 104 | + |
| 105 | +```yaml title=".github/workflows/ci.yml" |
| 106 | +- uses: 'moonrepo/setup-toolchain@v0' |
| 107 | + with: |
| 108 | + proto-version: '0.58.2' # renovate: datasource=github-releases depName=moonrepo/proto extractVersion=^v(?<version>.*)$ |
| 109 | +``` |
| 110 | + |
| 111 | +In formats that use `//` for comments (JSONC, Pkl, HCL), the `// renovate:` form works the same way: |
| 112 | + |
| 113 | +```json title=".moon/workspace.jsonc" |
| 114 | +{ |
| 115 | + "versionConstraint": ">=2.4.2" // renovate: datasource=github-releases depName=moonrepo/moon extractVersion=^v(?<version>.*)$ |
| 116 | +} |
| 117 | +``` |
| 118 | + |
| 119 | +To annotate versions in _other_ files — such as WASM plugin versions in `.prototools` — append their |
| 120 | +paths to `managerFilePatterns` in your own `customManagers` entry. |
| 121 | + |
| 122 | +### Datasource reference |
| 123 | + |
| 124 | +Useful when annotating a version, or adding a toolchain the structural manager doesn't cover. These |
| 125 | +mirror the datasources Renovate's native `proto` manager uses. |
| 126 | + |
| 127 | +| Tool | `datasource` | `depName` / `packageName` | `extractVersion` | |
| 128 | +| ---------- | ----------------- | ------------------------- | ----------------------- | |
| 129 | +| node | `node-version` | `node` | | |
| 130 | +| npm / pnpm | `npm` | `npm` / `pnpm` | | |
| 131 | +| yarn | `npm` | `@yarnpkg/cli` | | |
| 132 | +| rust | `github-tags` | `rust-lang/rust` | | |
| 133 | +| go | `github-tags` | `golang/go` | `^go(?<version>.*)$` | |
| 134 | +| python | `github-tags` | `python/cpython` | `^v(?<version>.*)$` | |
| 135 | +| deno | `github-releases` | `denoland/deno` | `^v(?<version>.*)$` | |
| 136 | +| bun | `github-releases` | `oven-sh/bun` | `^bun-v(?<version>.*)$` | |
| 137 | +| moon | `github-releases` | `moonrepo/moon` | `^v(?<version>.*)$` | |
| 138 | +| proto | `github-releases` | `moonrepo/proto` | `^v(?<version>.*)$` | |
| 139 | + |
| 140 | +## Tips and limitations |
| 141 | + |
| 142 | +- **Config format coverage.** Comment-free structural updates work for the `yml`, `yaml`, `json`, and |
| 143 | + `toml` formats; `jsonc`, `pkl`, and `hcl` are updated through `#` or `//` annotations. Strict `json` |
| 144 | + can't hold comments, so pin those toolchains structurally or in `.prototools`. |
| 145 | +- **Aliases are skipped.** Values like `latest`, `stable`, `canary`, or `nightly` can't be resolved |
| 146 | + to a concrete version, and are ignored. |
| 147 | +- **Pin each toolchain in one place.** Don't set the same version in both `.prototools` and |
| 148 | + `.moon/toolchains.yml` (or add an annotation on top of a structurally-managed version) — you'll get |
| 149 | + duplicate pull requests. |
| 150 | +- **Propagate changes on self-hosted Renovate.** You can run `moon sync` (or any command) after an |
| 151 | + update via [`postUpgradeTasks`](https://docs.renovatebot.com/configuration-options/#postupgradetasks) |
| 152 | + to keep generated files in sync.\ |
| 153 | + to batch toolchain bumps into a single pull request. |
0 commit comments