fix(deps): unpin tsx via catalog now that Node 24 regression is resolved

[binoy14]

Reverts the tsx <4.22.0 pin added in #922 to dodge a Node 24
regression in tsx's ?tsx-namespace= query propagation, which broke
@sanity/pkg-utils' pkg build (it loads package.config.ts via
tsImport from tsx/esm/api).

tsx 4.22.4 (privatenumber/tsx#803, "resolve CommonJS directory requires
inside dependencies") fixes the surface the SDK hits. Verified locally
on Node 24.13.0: clean core+react pkg build runs pass on 4.22.4.

Moves the version into a pnpm catalog so the root and @repo/e2e
share one source of truth instead of two literal specifiers, and drops
the now-unnecessary pnpm.overrides ceiling.

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

Description

What to review

Testing

Fun gif

[binoy14]

This change is part of the following stack:

• fix(deps): unpin tsx via catalog now that Node 24 regression is resolved #936 ◀

_{Change managed by git-spice.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sdk-docs	Ready	Preview, Comment	Jun 9, 2026 6:39pm
sdk-kitchensink-react	Ready	Preview, Comment	Jun 9, 2026 6:39pm

[claude]

Claude finished @binoy14's task in 47s —— View job

---

Review

• Read the diff (package.json, @repo/e2e/package.json, pnpm-workspace.yaml, lockfile)
• Verify catalog resolution & consistency

No actionable issues found. The change is correct and self-consistent:

• catalog.tsx: ^4.22.4 resolves cleanly to 4.22.4 in pnpm-lock.yaml (catalogs.default), and every transitive tsx@… reference in the lockfile is pinned to 4.22.4 — no split versions.
• Both consumers (root package.json:74 and @repo/e2e/package.json:50) reference catalog:, giving a single source of truth as described.
• The stale pnpm.overrides.tsx: "<4.22.0" ceiling is correctly dropped, and no other <4.22.0 / tsx-namespace references linger in the repo.

The ^4.22.4 floor includes the privatenumber/tsx#803 fix cited in the description, so the original Node 24 regression stays avoided. Looks good to merge once CI (incl. pkg build) passes.
· fix/unpin-tsx-node24

[github-actions]

⏳ Bundle Stats — Calculating bundle sizes for @sanity/sdk, @sanity/sdk-react...

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​tsx@​4.22.4

View full report

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🟢	Lines	95.47% (🎯 94%)	3865 / 4048
🟢	Statements	94.19% (🎯 93%)	4174 / 4431
🟢	Functions	94.93% (🎯 94%)	1086 / 1144
🟢	Branches	88% (🎯 86%)	2334 / 2652

File Coverage

No changed files found.

Generated in workflow #4273 for commit d9e1b0f by the Vitest Coverage Report Action

[binoy14]

Closing — the premise ("Node 24 regression is resolved") is incorrect. tsx 4.22.4 still breaks @sanity/pkg-utils' pkg build on Node 24.

The build (24) CI job failed with:

Error: ENOENT: no such file or directory, open 'node:os?tsx-namespace=...'
  at node:internal/modules/cjs/loader ...
  at tsx/dist/register-...mjs (the .js transformer hook)

Root cause is a Node patch-specific regression: tsx 4.22.4 passes on Node 24.13.0 (what local was running) but fails on Node 24.16.0 (what actions/setup-node@node-version:24 resolves to, and what .nvmrc pins). tsx's CJS loader hook appends ?tsx-namespace= to a node: built-in specifier, which the Node 24.16 CJS loader then tries to readFileSync.

This is tracked upstream and still open: privatenumber/tsx#801 (repro is literally @sanity/pkg-utils on Node 24). The <4.22.0 pin should stay until #801 is closed and released.