fix(yq): download the 64-bit binary on x86_64

[EliSchleifer]

The yq download maps x86_64: 386 on every platform. That has been there since the tool's original commit (#655) and reads as an oversight rather than a choice: x86_64 and arm_64 are the only cpu tokens a download can key on, so nothing was ever selecting 386 deliberately, and yq publishes amd64 for linux, darwin and windows at every version — including this definition's own known_good_version.

Two consequences today:

• Linux x86_64 silently gets yq_linux_386, a 32-bit binary. It runs on hosts with ia32 emulation, which is why this has gone unnoticed for ~18 months, but a host built without CONFIG_IA32_EMULATION cannot exec it. The failure is opaque — the install dies at the health check with a bare process failure on yq --version:

  Health check failed for 'yq'. Unexpected exception thrown while running HealthCheck
  Process failure: (... /cache/trunk/tools/yq/4.53.3-.../yq --version)
  

  Running it by hand is what points at the cause: exec format error, and file reports ELF 32-bit LSB executable, Intel 80386.

• macOS x86_64 points at yq_darwin_386, which yq has never published. I checked v4.20.2, v4.40.5, v4.44.1 and v4.53.3 — every one ships yq_darwin_amd64 and no darwin_386 — so an Intel Mac 404s and cannot install yq through this plugin at all.

The windows entry has the same mapping. yq_windows_386.exe does exist, so it "works", but it is 32-bit for the same non-reason; fixed alongside.

Verification

On linux x86_64, against a local plugin source carrying this file, both the requested version and the known_good_version install, pass the health check, and evaluate:

$ file .../yq
ELF 64-bit LSB executable, x86-64, statically linked
$ yq --version
yq (https://github.com/mikefarah/yq/) version v4.53.3
$ echo 'a: {b: 42}' | yq '.a.b'
42

trunk tools install yq succeeds for 4.53.3 and 4.44.1; before the change, 4.53.3 failed the health check on that host.

Alternatives considered

• Leave linux alone and fix only darwin. Rejected: the 32-bit linux binary is wrong regardless of whether a given kernel tolerates it, and the failure it produces when a kernel doesn't is unreadable.
• Add a separate 386 download entry for genuine 32-bit hosts. Nothing to key it on — trunk exposes no i386 cpu token — so there is no reachable case to serve.
• Switch to the .tar.gz assets (as the original commit did, before ec0900b moved to the bare binary). Out of scope; the bare-binary form works and changing it would touch the shim/extraction path for no benefit here.

No test changes: tools/yq/yq.test.ts is a toolInstallTest at the known_good_version, which is exactly the path this fixes, and it stays green.

🤖 Generated with Claude Code

[trunk-io]

😎 Merged successfully via direct-to-queue (branch protection was bypassed for this merge) - details.

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs