wranglerVersion is pinned to 3 in three release workflows with no owner but a code comment

[FrameAutomata]

Follow-up to #329, which pins wranglerVersion: "3" at all three Cloudflare deploy sites.

Why the pin exists

cloudflare/wrangler-action@v4 changed its default Wrangler CLI from 3 to 4. Neither website/package.json nor docs/package.json depends on wrangler (verified: zero hits in either package-lock.json), so the action's default is literally what deploys tracewayapp.com, the docs, and the chart index.

#329's purpose was moving off the Node 20 action runtime. Taking v4 unpinned would have carried a CLI major bump into that, on a production deploy path no PR label can exercise — so the pin holds the CLI where it is and the runtime moves alone. That was the right call for that PR and is the wrong thing to leave forever.

The problem with leaving it

The pin's exit condition is prose in three code comments. Wrangler 3 is already superseded, and unowned version state in this repo is exactly what #326 was about — it drifts until it becomes an annotation.

What "done" looks like

Not simply deleting the pin. The deeper fix for two of the three sites is making wrangler a devDependency of website/ and docs/: both workflows already run npm ci in the right working-directory and pass workingDirectory: to the action, and the action prefers a pre-installed wrangler when given no version input — so the deployed CLI becomes lockfile-pinned and Dependabot-trackable (see #330) instead of resolved at deploy time.

That covers 2 of 3. release-helm.yml:87 invokes the action with no workingDirectory and has no npm project anywhere near it (helm/ holds only the chart), running pages deploy deploy --project-name traceway-charts. Inventing a package.json purely to host one dependency would be worse than the pin; that site should keep an explicit wranglerVersion.

Validation

Wrangler 4's breaking changes need checking against website/wrangler.toml (a Worker with main, [assets], and [observability.traces]) and docs/wrangler.toml (assets-only). All three workflows are release-triggered, so this needs a workflow_dispatch dry run — release-helm.yml first, since it publishes only a chart index.

[FrameAutomata]

Correcting the Validation paragraph above, found while reviewing #332.

All three workflows are release-triggered, so this needs a workflow_dispatch dry run — release-helm.yml first, since it publishes only a chart index.

workflow_dispatch is not a dry run on this path. All three of these workflows deploy for real when dispatched:

• release-docs.yml / release-website.yml run cloudflare/wrangler-action with command: deploy and secrets.CLOUDFLARE_API_TOKEN — dispatching either one publishes to production Cloudflare from whatever ref you picked.
• release-helm.yml runs pages deploy deploy --project-name traceway-charts, which overwrites the live chart index. Lower stakes than the marketing site, but not a no-op — a broken index breaks helm repo update for every existing install.

So the plan in the issue body, followed literally, validates the Wrangler 4 migration by performing it in production. That is the opposite of what was intended.

What actually works for #331, in order:

1. Read the Wrangler 3→4 changelog against website/wrangler.toml (Worker with main, [assets], [observability.traces]) and docs/wrangler.toml (assets-only).
2. Make wrangler a devDependency of website/ and docs/ as the issue already proposes — that moves the CLI version into the lockfile, so npm ci + npm run build in a normal PR exercises it under the ci label without touching a deploy.
3. Only release-helm.yml is left needing an explicit wranglerVersion, and it is the one site with no npm project to host the dependency — so it keeps the pin, as the issue says.

Step 2 is what makes this validatable at all; without it there is no safe way to test the bump ahead of a real release.

[dusanstanojeviccs]

Real, we should lock down the version

[FrameAutomata]

Done in #347.

Reading installWrangler rather than going from the docs changed the answer here, and it's better than what I proposed in my earlier comment. The action uses an already-installed Wrangler when wranglerVersion is unset, and accepts an installed version that satisfies it when set — confirmed in src/wranglerAction.ts and in v3.15.0's dist/index.mjs, so it holds on the action major in use today, not just on v4. Both workflows already npm ci in the same workingDirectory the action is given, so a devDependency lands exactly where it looks.

So wrangler is now an exact devDependency of website/ and docs/ (3.114.17), and the version lives in package-lock.json. release-helm.yml has no npm project, so it stays the one site stating the version — exactly, not as a bare major, since "3" is a range the action re-resolves per deploy.

Worth recording what was actually unpinned: with no input, v3.15.0 falls back to DEFAULT_WRANGLER_VERSION = "3.90.0" and v4.0.0 to "4". So today it's an exact version nobody chose, and after an action bump it becomes a floating one.

3.x rather than 4 — locking down isn't migrating, and Wrangler 4 is a config migration (website/wrangler.toml is a Worker with main/[assets]/[observability.traces]). The gain is that it's now testable in a PR via npm ci, which it wasn't before.

I also aligned #344's helm block byte-for-byte with #347's so the two can't conflict.

---

Generated by Claude Code