mono - chore: upgrade build tooling

[jaredwray]

Please check if the PR fulfills these requirements

• Followed the Contributing guidelines and Code of Conduct
• Tests for the changes have been added (for bug fixes/features) with 100% code coverage. — N/A: dependency-only upgrade with no source changes; existing suites still pass at 100% coverage where runnable in this environment.

What kind of change does this PR introduce?

Maintenance (chore) — upgrades the non-major TypeScript / build tooling to their latest minimumReleaseAge-gated versions. No source or public-API changes. Second PR of the dependency-management dev phase.

Versions

• tsdown ^0.22.0 → ^0.22.3 (bundler; 8 packages: cacheable, cache-manager, file-entry-cache, flat-cache, @cacheable/memory, @cacheable/net, @cacheable/node-cache, @cacheable/utils)
• tsx 4.21.0 → 4.23.0 (@cacheable/benchmark, @cacheable/website — existing pin styles preserved: caret for benchmark, exact for website)
• @arethetypeswrong/cli ^0.18.3 → ^0.18.4 (root)

typescript (5.9.3 → 6.0.3) is a major and is deferred to its own PR; @types/node (24.12.2 → 26.1.0) is held pending a Node-major-version decision (.nvmrc says 22, but CI tests 22/24/26 and the current pin is ^24).

Verification

• pnpm build passes

• node scripts/test-build.mjs (build-output validation: runtime + publint + attw) passes for all packages

• pnpm test — every package passes at 100% coverage except the same 3 tests that fail on main and are specific to this sandbox (not caused by this change):

  • cacheable-request › return with url and port — real request to external mockhttp.org:8080, unreachable here (the :80 variant passes).
  • file-entry-cache › should return a file descriptor with checksum and error and normalizeEntries() › should return all entries — both chmod 0o000 a file to force a read error, but this sandbox runs as root, which bypasses permission bits.

  All three pass on GitHub CI (non-root runner, full network).

---

Generated by Claude Code

[gemini-code-assist]

Code Review

This pull request updates several development dependencies across the monorepo, including upgrading @arethetypeswrong/cli to ^0.18.4, tsx to ^4.23.0, and tsdown to ^0.22.3. The lockfile pnpm-lock.yaml has been regenerated to reflect these updates along with their transitive dependencies. I have no feedback to provide as there are no review comments.

[socket-security]

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

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	tsx@​4.23.0
	tsdown@​0.22.3
	@​arethetypeswrong/​cli@​0.18.4

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm @emnapi/runtime is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: pnpm-lock.yaml → npm/tsdown@0.22.3 → npm/@emnapi/runtime@1.11.1 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@emnapi/runtime@1.11.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (52c60fc) to head (587ed31).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1670   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           29        29           
  Lines         3504      3504           
  Branches       809       795   -14     
=========================================
  Hits          3504      3504           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jaredwray]

Re: Socket "Obfuscated code" alert on @emnapi/runtime@1.11.1 — reviewed, no action needed on the code.

• @emnapi/runtime is a legitimate, widely-used Node-API/WASM runtime (part of the emnapi / napi-rs ecosystem). The "90% likely obfuscated" flag is a known heuristic false positive on its generated/minified WASM-interop glue, not malicious obfuscation.
• It was already in the tree on main (@emnapi/runtime@1.9.2 and @1.10.0), pulled transitively via wrangler → miniflare → sharp → @img/sharp-wasm32 and @napi-rs/wasm-runtime.
• This PR's only effect on it: the tsdown 0.22.0 → 0.22.3 patch bump transitively moves @napi-rs/wasm-runtime 1.1.4 → 1.1.6, which resolves @emnapi/runtime@1.11.1 (up from 1.10.0) — same package, newer patch.
• It's a dev/build-time transitive dependency only (via the tsdown bundler and wrangler, both devDependencies); it is not a runtime dependency of any published @cacheable/* package.

The "Socket Security: Pull Request Alerts" check passed (this is a Warn-level advisory). I've deliberately not self-issued a @SocketSecurity ignore, since suppressing the alert is a maintainer triage decision — happy to add it or pin differently if you'd prefer.

---

Generated by Claude Code