chore: bump tsx from 4.21.0 to 4.23.11

[dependabot]

Bumps tsx from 4.21.0 to 4.23.11.

Release notes

Sourced from tsx's releases.

v4.23.11

4.23.11 (2026-08-07)

Bug Fixes

• preserve async ESM require fallback (55cbece)

---

This release is also available on:

• npm package (@​latest dist-tag)

v4.23.10

4.23.10 (2026-08-07)

Bug Fixes

• support nyc coverage discovery (#710) (ec1bcd5)

---

This release is also available on:

• npm package (@​latest dist-tag)

v4.23.9

4.23.9 (2026-08-06)

Bug Fixes

• map Node test locations (2f55884)
• support data URLs in tsImport (b94f46f)

---

This release is also available on:

• npm package (@​latest dist-tag)

v4.23.8

4.23.8 (2026-08-05)

Bug Fixes

• preserve package subpath resolution (be1315e)
• preserve typeless ESM dependency exports (70dfc5e)

---

This release is also available on:

• npm package (@​latest dist-tag)

... (truncated)

Commits

• bd3bc64 test: cover CommonJS loader source fallback
• 55cbece fix: preserve async ESM require fallback
• 6c5ba85 docs: document CommonJS default interop
• ec1bcd5 fix: support nyc coverage discovery (#710)
• b6e5b48 docs: clarify CommonJS default imports
• 2f55884 fix: map Node test locations
• de935d5 docs: document Node source-map stack formatting
• b94f46f fix: support data URLs in tsImport
• be1315e fix: preserve package subpath resolution
• 5efba41 docs: organize transform backend research
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for tsx since your current version.

[claude]

Claude finished @dependabot[bot]'s task in 2m 21s —— View job

---

Dependency review: tsx 4.21.0 → 4.23.11

• Identify version change / semver scope
• Review release notes for breaking or behaviour changes
• Find how tsx is used in this repo
• Check what the +495/-28 lockfile diff actually is
• Check CI

Verdict: safe to merge. Dev-only, minor bump within 4.x, and the one place we use tsx doesn't touch any of the fixed code paths.

---

1. Scope

Minor bump, no major crossing. package.json is unchanged — the existing "tsx": "^4.19.0" range already admits 4.23.11, so this is a lockfile-only pin refresh. tsx is a devDependency, and the published package ships files: ["dist"], so there is zero impact on the npm package, the .mcpb bundle, or runtime behaviour for users.

Engines are fine: tsx@4.23.11 declares node >= 18.0.0, comfortably under this repo's engines: node >= 20.

2. Why the diff is 495 lines (the only thing worth noting)

Not bloat from tsx itself — it's a dependency-tree de-dup that stopped working:

	before (4.21.0)	after (4.23.11)
tsx → esbuild range	~0.27.x	~0.28.0 (package-lock.json:2453)
resolution	deduped to top-level esbuild@0.27.7	nested node_modules/tsx/node_modules/esbuild@0.28.2 (package-lock.json:2907)
get-tsconfig + resolve-pkg-maps	present	dropped (no longer declared deps)

vite (via vitest) requires esbuild@^0.27.0 (package-lock.json:3009), so it holds the top-level slot at 0.27.7. tsx's move to ~0.28.0 forces a second copy plus all 26 platform-specific @esbuild/* optional packages — that accounts for essentially the whole +495. The -28 is the two removed get-tsconfig/resolve-pkg-maps entries.

Practical consequences, all minor and dev-only:

• npm ci now downloads two esbuild native binaries instead of one — slightly slower/larger dev installs.
• Both esbuild entries are hasInstallScript: true. Worth knowing if anyone audits or considers --ignore-scripts; it's not a new class of risk (esbuild was already there), just a second instance.
• This resolves itself when vitest/vite catch up to esbuild 0.28.

esbuild 0.27 → 0.28 is the biggest behaviour change riding along here, but we only use esbuild transitively as tsx's TS→JS transform for a Node-executed script (no bundling, no output artifact), so the exposure is small.

3. How tsx is actually used

Exactly one call site, and it's narrow:

• package.json:20 — "generate-catalog": "tsx scripts/generate-catalog.ts"
• .github/workflows/update-catalog.yml:33 — npm run generate-catalog (weekly catalog regeneration PR)

scripts/generate-catalog.ts:1-6 imports only node:fs / node:path / node:url, one type-only import, and two relative .js-extension local modules. No CommonJS interop, no tsImport, no data URLs, no nyc, no node:test.

Cross-referencing that against the 4.22–4.23 fixes: CommonJS loader source fallback / async ESM require fallback, data URLs in tsImport, nyc coverage discovery, Node test location mapping, typeless ESM dependency exports, package subpath resolution — none of them intersect this usage. Plain ESM importing node builtins and sibling files is the most conservative path through tsx.

4. Risks and follow-ups

• ⚠️ CI does not exercise tsx. ci.yml runs build + test + .mcpb smoke test; none of those invoke tsx. The green CI run (31503339363) is therefore not evidence that tsx still works. The first real exercise is the next weekly update-catalog.yml run. That's an acceptable place to find out — a failure there just means no catalog PR that week, with no user-facing impact — but if you want certainty before merging, run npm run generate-catalog locally once and confirm src/catalog.json regenerates with no diff beyond genuine API changes.
• ℹ️ Publisher change, flagged in the PR body itself: tsx is now pushed to npm by GitHub Actions, a new releaser for this package. That's a human→CI publishing shift (usually an improvement, and it enables provenance), but it is a supply-chain change worth a conscious ack rather than a silent one, given this repo's care around pinning and signed commits.
• ✅ No typescript, vitest, @types/node, @modelcontextprotocol/sdk, or GitHub Actions pins are touched by this PR, so strict: true, the NodeNext + .js-extension convention, tool annotations in src/index.ts, and the SHA-pinning style are all unaffected.

I could not run npm ci / npm test / npm run generate-catalog in this review environment (install and network access were not permitted), so section 3–4 conclusions come from reading the lockfile, package.json, the scripts, and the workflows rather than from executing them. Release notes beyond those quoted in the PR body (i.e. the truncated 4.22.x–4.23.7 range) were also not fetchable here — my read of that range is based on the commit list in the PR body.
· branch dependabot/npm_and_yarn/tsx-4.23.11

[dependabot]

Superseded by #44.

[dangrondahl]

@dependabot rebase

[dependabot]

Looks like this PR is closed. If the branch still exists, you can re-open the PR and then use @dependabot rebase or @dependabot recreate. If the branch was deleted, Dependabot will create a new PR on the next scheduled run, or you can trigger an update from the Dependency graph page.