chore(build): upgrade repo tooling to latest versions

[alex-connolly]

Summary

• Upgrade from TypeScript 5.6 to dual 6/7: native TypeScript 7 as tsc (@typescript/native), TypeScript 6 API via typescript → @typescript/typescript6
• Switch package builds from tsup (esbuild) to tsdown (rolldown), with a shared tsdown.base.ts browser/node preset
• Replace ESLint with Oxlint (oxlint + oxlint-tsgolint@7, type-aware enabled); wire pnpm lint / lint-staged / PR CI to Oxlint only
• Migrate to pnpm 11 best practices (catalogs, overrides, peer rules) and drop syncpack / husky in favor of catalogs + lefthook

Published package surfaces (exports / main / module / browser / types / dependency keys) are unchanged for the SDK packages.

No public API shape changes. Consumer-facing entrypoints and package.json contract fields match main.

Small logic tweaks (not interface redesigns):

1. @imtbl/checkout-widgets — BridgeReviewSummary
   If from.browserProvider.provider is missing, it now opens the switch-network drawer and returns instead of calling .send('eth_chainId') and throwing. Type-driven hardening with a real runtime behavior change on that edge case.

2. @imtbl/bridge-sdk — withBridgeError
   Fixes dead || 'UnknownError' after a template string. Empty/undefined error messages become "Type: UnknownError" instead of "Type: undefined".

3. SegmentAnalyticsProvider
   Type-only: dropped a generic type arg and cast AnalyticsProvider for TS portability. No runtime change.

Everything else in src/ is comments, tests, sample-app layout, or CI action cleanup.

Indirect runtime note: browser bundles no longer inject the Node Buffer polyfill. That’s build output, not an exported API. Fine if code only guards typeof Buffer (as metrics does); would matter only if something relied on that polyfill being present as a side effect of loading the bundle.

Design decisions

Why tsup → tsdown

• tsdown is the maintained successor path for our bundling needs (Rolldown/Oxc stack), with first-class TS support and better alignment with the rest of this toolchain upgrade.
• A shared tsdown.base.ts preset replaces per-package tsup boilerplate so browser/node outputs, minify, and polyfill behavior stay consistent.
• Side effect: browser builds no longer force-inject Node Buffer/process polyfills via esbuild-plugins-node-modules-polyfill (see bundle sizes below). Metrics only guards those globals (typeof Buffer, process.env…); the old plugin still shipped ~31 KB of polyfill into anything that inlined metrics.

Why dual TypeScript 6/7

• TS 7 (@typescript/native) is what we run for tsc / typecheck speed.
• TS 6 stays on the typescript package name (@typescript/typescript6) so tools that still expect the TS 6 API (and peer ranges) keep working during the ecosystem transition.

Why Oxlint (and not ESLint)

• Faster lint, native type-aware rules via oxlint-tsgolint, one monorepo command (pnpm lint) instead of per-package ESLint configs.
• Naming rules use eslint/id-match instead of @typescript-eslint/naming-convention. Legacy eslint-disable comments are inert and can be cleaned up later.

Why pnpm 11 catalogs / overrides / peer rules

• pnpm 11 expects workspace settings in pnpm-workspace.yaml (.npmrc is auth/registry only).
• Named catalogs (toolchain / react / testing / web3) + catalogMode: strict replace syncpack for shared version policy and stop ad-hoc versions creeping back via pnpm add.
• Yarn-style package.json#resolutions is ignored by pnpm 11 — moved to workspace overrides (e.g. elliptic single-version).
• peerDependencyRules + dedupePeers codify known React 19 / TS 6–7 peer noise instead of ignoring install dumps.
• No global injectWorkspacePackages: audience still uses prepack to strip bundled workspace deps from published metadata; selective dependenciesMeta.*.injected can be evaluated later if packing needs it.
• Jest maps @imtbl/* to workspace src so tests don’t depend on publicHoistPattern: ['@imtbl/*'] (hoist kept for rollup/tsc transitive resolution for now).

Why lefthook

• Replaces husky for git hooks; prepare installs hooks with --reset-hooks-path so local hook wiring stays predictable across pnpm 11.

Bundle size impact (main → this branch)

Measured from clean nx run-many -t build on origin/main (a9d70c9) vs this branch (32ccfeae). Sizes are gzip via gzip -c (same as CI budget workflows).

Why sizes moved

1. Primary (~10 KB gzip on metrics / audience): dropped forced Node Buffer/process polyfills from the browser preset (tsup esbuild plugin → tsdown rollup-plugin-polyfill-node).
2. Secondary: tsup → tsdown minify/treeshake differences (usually small).
3. Pixel never bundled real metrics (local stub), so it only sees (2).

CDN / script-tag bundles (CI budgets)

Package	main gzip	branch gzip	Δ	Why
@imtbl/audience	21.0 KB	11.0 KB	−10.0 KB (−47.6%)	CDN inlines metrics → drops Buffer polyfill
@imtbl/pixel	6.9 KB	6.8 KB	−98 B (−1.4%)	Metrics stubbed; minify noise only
@imtbl/sdk	759.9 KB	662.4 KB	−97.5 KB (−12.8%)	Umbrella CDN; slimmer dependency graph + minify

Browser ESM package entries

Package	main gzip	branch gzip	Δ	Why
@imtbl/metrics	12.2 KB	2.5 KB	−9.8 KB (−79.9%)	Root cause: Buffer/process polyfill removed
@imtbl/audience	20.8 KB	10.6 KB	−10.2 KB (−49.0%)	Inherits metrics polyfill removal
@imtbl/auth	25.3 KB	15.4 KB	−10.0 KB (−39.4%)	Same forced-polyfill removal in shared browser preset
@imtbl/orderbook	20.7 KB	12.1 KB	−8.5 KB (−41.3%)	Same (Buffer polyfill references largely gone)
@imtbl/checkout-sdk	37.2 KB	27.7 KB	−9.4 KB (−25.3%)	tsup→tsdown bundling/treeshake + polyfill preset change
@imtbl/dex-sdk	31.4 KB	30.4 KB	−1.1 KB (−3.4%)	Minify/treeshake under tsdown
@imtbl/wallet	22.8 KB	22.2 KB	−666 B (−2.8%)	Minify variance
@imtbl/passport	2.6 KB	2.6 KB	−14 B (−0.5%)	Minify variance
@imtbl/audience-core	5.5 KB	5.4 KB	−125 B (−2.2%)	Minify variance
@imtbl/bridge-sdk	12.9 KB	12.7 KB	−229 B (−1.7%)	Minify variance
@imtbl/blockchain-data	1.3 KB	1.3 KB	−10 B (−0.7%)	Minify variance
@imtbl/generated-clients	12.6 KB	12.2 KB	−453 B (−3.5%)	Minify variance
@imtbl/cryptofiat	782 B	754 B	−28 B (−3.6%)	Minify variance
@imtbl/config	506 B	494 B	−12 B (−2.4%)	Minify variance
@imtbl/toolkit	462 B	445 B	−17 B (−3.7%)	Minify variance
@imtbl/sdk (entry)	572 B	180 B	−392 B (−68.5%)	Thin re-export entry only; see CDN row for real payload

Deferred / skip

• pnpm patch — no local monkey-patches; seaport remains intentional git deps via @imtbl/contracts
• Narrowing publicHoistPattern further (still needed for rollup/tsc transitive workspace resolution)
• Raising networkConcurrency until seaport yarn-prepare races are gone
• Selective dependenciesMeta.*.injected — evaluate later if packing needs it

[github-actions]

✅ Pixel Bundle Size — @imtbl/pixel

Metric	Size	Delta vs main
Gzipped	6968 bytes (6.80 KB)	-101 bytes
Raw (minified)	19325 bytes	+244 bytes

Budget: 10.00 KB gzipped (warn at 8.00 KB)

[github-actions]

✅ Audience Bundle Size — @imtbl/audience

Metric	Size	Delta vs main (a9d70c9)
Gzipped	11236 bytes (10.97 KB)	-10273 bytes
Raw (minified)	31391 bytes	-31236 bytes

Budget: 24.00 KB gzipped (warn at 20.00 KB)

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 32ccfea

Command	Status	Duration	Result
nx run-many -p @imtbl/sdk,@imtbl/checkout-widge...	✅ Succeeded	1s	View ↗
nx affected -t build,test	✅ Succeeded	10s	View ↗

💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗

---

☁️ Nx Cloud last updated this comment at 2026-07-27 22:49:52 UTC

[socket-security]

Warning

According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. It is recommended to resolve "Warn" alerts too. Learn more about Socket for GitHub.

Please tag @prodsec or slack us at #ask-security if you need assitance.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm @nx/workspace is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: pnpm-lock.yaml → npm/@nx/js@23.1.0 → npm/@nx/workspace@23.1.0 ℹ 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/@nx/workspace@23.1.0. 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.
Warn		Obfuscated code: npm embla-carousel is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: pnpm-lock.yaml → npm/@biom3/react@0.29.11 → npm/embla-carousel@8.6.0 ℹ 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/embla-carousel@8.6.0. 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.
Warn		Obfuscated code: npm execa is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: pnpm-lock.yaml → npm/@nx/js@23.1.0 → npm/execa@9.6.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/execa@9.6.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.
Warn		Obfuscated code: npm nx is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package.json → npm/nx@23.1.0 ℹ 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/nx@23.1.0. 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.
Warn		Obfuscated code: npm strtok3 is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: pnpm-lock.yaml → npm/@nx/js@23.1.0 → npm/strtok3@10.3.5 ℹ 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/strtok3@10.3.5. 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