build: pin devDependencies to caret ranges instead of latest

[claude]

Summary

Pins all 10 devDependencies that used latest to caret ranges, matching the versions currently resolved in bun.lock. This includes semantic-release and its plugins (which run in the publish path), typescript, and @biomejs/biome — exactly the packages called out in the issue.

Reproducibility was protected today by bun.lock + bun install --frozen-lockfile, but a lockfile regeneration could silently pull a new major into the build/release pipeline. Caret ranges close that gap while still allowing minor/patch updates.

package	range
@arethetypeswrong/cli	^0.18.3
@biomejs/biome	^2.4.10
bun-types	^1.3.11
dts-bundle-generator	^9.5.1
lefthook	^2.1.4
semantic-release	^25.0.3
@semantic-release/changelog	^6.0.3
@semantic-release/git	^10.0.1
@semantic-release/github	^12.0.8
@semantic-release/npm	^13.1.5
typescript	^6.0.2

zod was already ^4.0.0 and is left untouched.

Verification

• bun install --frozen-lockfile → exit 0, bun.lock unchanged (every caret base matches the lockfile-resolved version)
• bunx biome check . → pass
• bunx tsc --noEmit → pass
• bun test → 113 pass / 0 fail

Files changed

• package.json — latest → caret ranges in devDependencies
• docs/specs/issue-20-...md — implementation plan artifact

Plan level: lean · depth: medium

Closes #20

Generated with Claude Code

[greptile-apps]

Greptile Summary

Pins all 10 devDependencies that used "latest" to caret ranges matching the versions already resolved in bun.lock, closing the gap where a future lockfile regeneration could silently pull in a new major version. Both package.json and the workspace metadata block in bun.lock are updated together, keeping them in sync.

• package.json: each "latest" entry is replaced with a ^x.y.z caret range whose base matches the currently-resolved lockfile version (e.g., "typescript": "^6.0.2", "@biomejs/biome": "^2.4.10").
• bun.lock: the workspaces section now records the same caret specifiers, so bun install --frozen-lockfile continues to pass without regenerating the lockfile.
• docs/specs/...: a new implementation-plan artifact captures rationale, acceptance criteria, and verification steps.

Confidence Score: 5/5

Configuration-only change that only updates version specifiers; no runtime code is touched and both package.json and bun.lock are kept in sync.

The change is mechanical — every 'latest' is replaced with a caret range whose base matches the already-resolved lockfile entry, and the lockfile's workspace metadata is updated in the same commit. There is no executable code modification, and the PR description confirms bun install --frozen-lockfile, lint, type-check, and the full test suite all pass.

No files require special attention.

Important Files Changed

Filename	Overview
package.json	Replaces "latest" with caret ranges for all 10 devDependencies; versions match the lockfile-resolved entries in bun.lock.
bun.lock	Workspace metadata in the lockfile updated from "latest" to the matching caret ranges, keeping it in sync with package.json.
docs/specs/issue-20-pin-devdependencies-to-ranges-instead-of-latest.md	New implementation plan artifact documenting the rationale, acceptance criteria, and verification steps for this change.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[package.json\ndevDependencies] -->|was 'latest'| B[Non-reproducible\nfresh installs]
    A -->|now caret ranges\ne.g. ^6.0.2| C[Reproducible ranges]
    C --> D[bun.lock\nworkspace metadata\nalso updated]
    D --> E{bun install\n--frozen-lockfile}
    E -->|exit 0, no churn| F[CI passes ✓]
    E -->|lockfile diverges| G[CI fails — catches drift]

Loading

_{Reviews (2): Last reviewed commit: "build: reconcile bun.lock workspace spec..." | Re-trigger Greptile}

[beogip]

@claude check the comment

[claude]

Claude finished @beogip's task in 1m 35s —— View job

---

Checked the review comment ✅

Greptile flagged that bun.lock's workspaces block still recorded "latest" and claimed this would make CI's bun install --frozen-lockfile fail.

I verified both claims locally on this branch:

Check	Result
bun install --frozen-lockfile	exit 0, bun.lock unchanged — CI does not fail
Was the workspaces block still "latest"?	Yes — Greptile's factual observation was correct
Non-frozen bun install diff	11/11 lines, only the specifier strings; zero resolved-version or integrity-hash changes

Verdict: Greptile was right about the cosmetic divergence but wrong about the consequence. Frozen-lockfile integrity is validated against the resolved package versions (which all satisfy the new caret ranges), not against the original specifier strings stored in workspaces. So the PR was already safe to merge — the author's verification in the description was accurate.

That said, the divergence is real and worth tidying, so I reconciled it:

• ✅ Committed 2d4ea45 — ran a non-frozen bun install so the workspaces block now reads the caret ranges instead of "latest". Only those 11 specifier strings changed; no dependency was added, removed, or re-resolved.
• ✅ Pushed to claude/issue-20-20260608-0304

The lockfile is now fully consistent with package.json, and the review thread is resolved with no behavioral change.
· branch claude/issue-20-20260608-0304