Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor: canary esm build and deprecating packages #535

Draft
wants to merge 10 commits into
base: dev
Choose a base branch
from

Conversation

ThomasRalee
Copy link
Collaborator

@ThomasRalee ThomasRalee commented Jan 20, 2025

Summary by CodeRabbit

I'll craft concise release notes highlighting the key changes and improvements across the project.

Release Notes

  • Module System Transition

    • Migrated to ECMAScript (ESM) modules across packages
    • Updated import/export syntax for better compatibility
  • Error Handling Improvements

    • Standardized gRPC error code processing
    • Enhanced error reporting mechanism in multiple API classes
  • Cryptography Enhancements

    • Updated cryptographic utility functions
    • Improved key and address management utilities
  • Dependency Updates

    • Updated core dependencies
    • Consolidated and streamlined package configurations
  • Test Utilities

    • Reorganized test utilities
    • Updated mock data generation mechanisms
  • Performance Optimizations

    • Refined module resolution strategies
    • Improved TypeScript compilation configurations

These release notes provide a high-level overview of the significant changes while maintaining confidentiality about specific implementation details.

Copy link

coderabbitai bot commented Jan 20, 2025

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

The changes represent a comprehensive refactoring and modernization of the Injective Protocol's TypeScript SDK and related packages. The modifications span multiple areas, including module system transitions, error handling improvements, cryptographic utility updates, and dependency management. Key focus areas include migrating to ECMAScript modules, standardizing error code processing, updating cryptographic functions, and removing the test-utils package.

Changes

File/Module Change Summary
Multiple Packages Transition to ES Modules with "type": "module"
Exceptions Package Added GrpcErrorCode enum and grpcErrorCodeToErrorCode function
SDK Packages Updated error handling to use grpcErrorCodeToErrorCode
Crypto Utilities Replaced cryptographic libraries, added address generation functions
Test Utilities Removed standalone package, migrated utilities to utils

Poem

🐰 A Rabbit's Refactoring Tale

In modules green and errors bright,
We dance through code with pure delight,
ES modules sing, exceptions gleam,
Our SDK flows like a smooth stream! 🌈

Hop, hop, refactor! 🚀


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

socket-security bot commented Jan 20, 2025

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert Package NoteSourceCI
Critical CVE npm/@babel/[email protected] ⚠︎

View full report↗︎

Next steps

What is a critical CVE?

Contains a Critical Common Vulnerability and Exposure (CVE).

Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies.

Take a deeper look at the dependency

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 [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

@ThomasRalee ThomasRalee marked this pull request as draft January 20, 2025 20:05
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 9

🔭 Outside diff range comments (10)
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)

Line range hint 16-180: Improve test robustness and error handling.

The test suite could be improved in several ways:

  1. Tests currently swallow errors and only log them, which means they'll pass even when API calls fail
  2. No validation of error scenarios
  3. Missing test coverage for edge cases (e.g., invalid dates, malformed account addresses)

Consider refactoring the tests to:

  1. Remove try-catch blocks and let Jest handle the errors
  2. Add negative test cases
  3. Add validation for edge cases

Example refactor for one test:

 test('fetchHistoricalBalance', async () => {
-  try {
-    const response = await indexerGrpcArchiverApi.fetchHistoricalBalance({
-      account,
-      resolution,
-    })
-
-    expect(response).toBeDefined()
-    expect(response).toEqual(
-      expect.objectContaining<
-        ReturnType<
-          typeof IndexerGrpcArchiverTransformer.grpcHistoricalBalanceResponseToHistoricalBalances
-        >
-      >(response),
-    )
-  } catch (e) {
-    console.error(
-      'IndexerGrpcArchiverApi.fetchHistoricalBalance => ' +
-        (e as any).message,
-    )
-  }
+  const response = await indexerGrpcArchiverApi.fetchHistoricalBalance({
+    account,
+    resolution,
+  })
+
+  expect(response).toBeDefined()
+  expect(response).toEqual(
+    expect.objectContaining<
+      ReturnType<
+        typeof IndexerGrpcArchiverTransformer.grpcHistoricalBalanceResponseToHistoricalBalances
+      >
+    >(response),
+  )
+})
+
+test('fetchHistoricalBalance handles invalid account', async () => {
+  await expect(
+    indexerGrpcArchiverApi.fetchHistoricalBalance({
+      account: 'invalid-account',
+      resolution,
+    })
+  ).rejects.toThrow()
 })
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)

Line range hint 15-33: Improve test robustness and error handling.

The current test implementation has several issues:

  1. Test will pass even if an error occurs (errors are only logged)
  2. Missing assertion count to ensure all assertions are executed
  3. Missing error scenarios

Consider this improved implementation:

 describe('IndexerGrpcAccountPortfolioApi', () => {
   test('fetchAccountPortfolio', async () => {
+    expect.assertions(2);
     try {
       const response = await indexerGrpcPortfolioApi.fetchAccountPortfolio(
         injectiveAddress,
       )

       expect(response).toBeDefined()
       expect(response).toEqual(
         expect.objectContaining<
           ReturnType<
             typeof IndexerGrpcAccountPortfolioTransformer.accountPortfolioResponseToAccountPortfolio
           >
         >(response),
       )
     } catch (e) {
-      console.error(
-        'IndexerGrpcAccountPortfolioApi.fetchAccountPortfolio => ' +
-          (e as any).message,
-      )
+      throw e
     }
   })
+
+  test('fetchAccountPortfolio handles errors', async () => {
+    expect.assertions(1);
+    const invalidAddress = 'invalid-address';
+    
+    await expect(
+      indexerGrpcPortfolioApi.fetchAccountPortfolio(invalidAddress)
+    ).rejects.toThrow();
+  })
 })
packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)

Line range hint 11-170: Improve test error handling and coverage.

The test suite has several areas for improvement:

  1. Tests currently catch and log errors without failing, which could mask test failures
  2. Error handling code is duplicated across all tests
  3. Missing test cases for error scenarios

Consider refactoring the tests using this pattern:

describe('OLPGrpcApi', () => {
  // Common error handler
  const handleTestError = (methodName: string) => (error: unknown) => {
    console.error(`OLPGrpcApi.${methodName} => ${(error as Error).message}`);
    throw error; // Re-throw to fail the test
  };

  // Example of improved test structure
  test('fetchEpochs', async () => {
    const response = await dmmGrpcApi.fetchEpochs().catch(handleTestError('fetchEpochs'));
    
    expect(response).toBeDefined();
    expect(response).toEqual(
      expect.objectContaining<ReturnType<typeof DmmGrpcTransformer.epochsResponseToEpochs>>(response),
    );
  });

  // Add error scenario tests
  test('fetchEpochs handles network errors', async () => {
    const errorApi = new OLPGrpcApi('invalid-url');
    await expect(errorApi.fetchEpochs()).rejects.toThrow();
  });
});
packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (1)

Line range hint 78-82: Fix incorrect error context string.

The error context string in fetchDenomAuthorityMetadata is incorrect. It's using 'TokenFactoryDenomsFromCreator' instead of 'TokenFactoryDenomAuthorityMetadata'.

Apply this fix:

  throw new GrpcUnaryRequestException(new Error(e.toString()), {
    code: grpcErrorCodeToErrorCode(e.code),
-   context: 'TokenFactoryDenomsFromCreator',
+   context: 'TokenFactoryDenomAuthorityMetadata',
    contextModule: this.module,
  })
packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (1)

Line range hint 208-223: Update error handling in deprecated broadcastBlock method.

The deprecated broadcastBlock method still uses the removed GeneralException. Consider updating it to use the new error handling pattern before removal.

Apply this diff to update the error handling:

-        throw new GeneralException(
-          new Error('There was an issue broadcasting the transaction'),
-        )
+        throw new GrpcUnaryRequestException(
+          new Error('There was an issue broadcasting the transaction'),
+          {
+            context: 'TxGrpcApi',
+            contextModule: 'broadcast-block',
+          },
+        )
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)

Line range hint 424-426: Remove duplicate condition check for before parameter.

The before condition is checked twice in the fetchTxs method, which is redundant.

Apply this diff to remove the duplicate check:

    if (before) {
      request.before = before.toString()
    }

    if (startTime) {
      request.startTime = startTime.toString()
    }

-   if (before) {
-     request.before = before.toString()
-   }

    if (endTime) {
      request.endTime = endTime.toString()
    }

Also applies to: 445-447

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (1)

Implement the commented out isConditional parameter code

The isConditional parameter is actively used in the derivatives API and should be implemented in the spot API for feature parity. The implementation is already written but commented out.

  • Uncomment the isConditional implementation in both methods
  • Fix the spacing in request.isConditional =isConditional to request.isConditional = isConditional
🔗 Analysis chain

Line range hint 164-166: Address commented out code for isConditional parameter.

There are commented out code blocks for the isConditional parameter in multiple methods. These should either be implemented or removed to maintain code cleanliness.

Please verify if this feature is still needed. If it is:

  1. Implement the feature
  2. Add appropriate tests
    If not, remove the commented code.

Also applies to: 275-277

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if isConditional is used elsewhere in the codebase

# Search for isConditional usage
rg "isConditional" --type ts

Length of output: 1895


Script:

#!/bin/bash
# Get the full context of methods using isConditional in spot API
ast-grep --pattern 'function $_($$$) {
  $$$
  if (isConditional !== undefined) {
    $$$
  }
  $$$
}' packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts

# Also get the commented sections mentioned in the review
rg -A 2 -B 2 "isConditional" packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts

Length of output: 761

packages/utils/jest.config.js (1)

Line range hint 5-7: Update tsConfig to tsconfig in ts-jest configuration.

The ts-jest configuration uses tsConfig, which has been deprecated. Update it to tsconfig to align with the latest ts-jest options.

Apply this diff:

   globals: {
     'ts-jest': {
-      tsConfig: 'tsconfig.build.esm.json',
+      tsconfig: 'tsconfig.build.esm.json',
     },
   },
packages/exceptions/jest.config.js (1)

Line range hint 5-7: Update tsConfig to tsconfig in ts-jest configuration.

Similar to the change in packages/utils/jest.config.js, update tsConfig to tsconfig in the ts-jest configuration for consistency and to use the correct option name.

Apply this diff:

   globals: {
     'ts-jest': {
-      tsConfig: 'tsconfig.build.esm.json',
+      tsconfig: 'tsconfig.build.esm.json',
     },
   },
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (1)

Line range hint 256-256: Fix incorrect event listener name.

The event listener is using 'leap_keystorechange' instead of 'ninji_keystorechange', which is inconsistent with the wallet type.

Apply this diff to fix the event name:

-    window.addEventListener('leap_keystorechange', listener)
+    window.addEventListener('ninji_keystorechange', listener)
🧹 Nitpick comments (19)
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts (1)

3-4: Consider the impact of updating deprecated packages.

This file is in a deprecated package but is still receiving updates. This could mislead users into thinking the package is still maintained.

Consider either:

  1. Moving the actively maintained code to a new package
  2. Adding clear deprecation notices with migration paths for users
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)

Line range hint 35-61: Remove commented out code.

If the fetchAccountPortfolioTokenHolders test is no longer needed, remove it entirely. If it's still relevant, implement it properly. Keeping commented out code reduces maintainability.

packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)

Line range hint 23-25: Standardize error handling across tests.

The error handling in the test suite has several inconsistencies:

  1. Unsafe type casting with as any
  2. String concatenation instead of template literals
  3. Inconsistent error message formatting

Consider standardizing error handling:

// Create a typed error handler
type GrpcError = Error & { code?: number; message: string };

const formatErrorMessage = (method: string, error: GrpcError) => 
  `OLPGrpcApi.${method} failed: ${error.message}${error.code ? ` (code: ${error.code})` : ''}`;

// Usage in tests
} catch (error) {
  console.error(formatErrorMessage('fetchEpochs', error as GrpcError));
}

Also applies to: 45-47, 68-71, 89-91, 112-115, 136-138, 159-162

packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (1)

2-2: Consider documenting the ESM migration strategy.

The use of '.js' extensions in imports and the consolidation of utility packages indicate a transition to ECMAScript modules. Consider:

  1. Documenting the migration strategy
  2. Updating the package.json type field
  3. Adding ESM-specific export maps
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (1)

1-1: Consider using explicit file extension for local imports.

For consistency with ECMAScript modules, consider adding the .js extension to the local import.

-import MsgCancelBinaryOptionsOrder from './MsgCancelBinaryOptionsOrder'
+import MsgCancelBinaryOptionsOrder from './MsgCancelBinaryOptionsOrder.js'
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)

Line range hint 61-61: Address TODO comment in fetchModuleState.

The TODO comment in the response handling needs to be addressed for completeness.

Would you like me to help implement the proper state handling for the module state response?

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcWeb3GwApi.ts (1)

12-12: Consider standardizing error type handling.

While the error code standardization is good, consider also standardizing the error type handling. Currently, e.type is directly passed through while error codes are transformed.

 throw new TransactionException(new Error(e.toString()), {
-  type: e.type,
+  type: ErrorType.Web3Gateway,
   context: 'Web3Gateway.PrepareEip712',
   code: grpcErrorCodeToErrorCode(e.code),
 })

Also applies to: 106-107

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (1)

Line range hint 47-48: Consider type-safe error message checking.

The current error message check uses unsafe type casting with as any. Consider implementing a type-safe error check.

-if ((e as any)?.message === 'account address not found') {
+if (e instanceof Error && e.message === 'account address not found') {

Also applies to: 88-89

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts (1)

3-4: LGTM! Consider enhancing error type checking.

The standardized error handling looks good. However, in the fetchOraclePriceNoThrow method, consider using a more type-safe approach for checking 'object not found' errors.

-      if ((e as any).message.includes('object not found')) {
+      if (e instanceof Error && e.message.includes('object not found')) {

Also applies to: 39-39, 83-83, 133-133

packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (1)

1-1: Well-structured refactoring with consistent patterns.

The changes demonstrate a well-thought-out refactoring approach with two main improvements:

  1. Service separation through dedicated explorer endpoints
  2. Standardized error handling using grpcErrorCodeToErrorCode

The modifications are consistently applied across different modules and environments, improving maintainability and reliability.

packages/exceptions/src/exceptions/types/codes.ts (1)

23-27: Consider adding validation in the error code conversion.

The current implementation assumes the input is always a valid gRPC error code. Consider adding validation to handle invalid codes gracefully.

 export const grpcErrorCodeToErrorCode = <T extends number>(
   grpcErrorCode: T,
 ): GrpcErrorCode => {
-  return grpcErrorCode as GrpcErrorCode
+  if (grpcErrorCode >= GrpcErrorCode.OK && grpcErrorCode <= GrpcErrorCode.Unauthenticated) {
+    return grpcErrorCode as GrpcErrorCode
+  }
+  return GrpcErrorCode.Unknown
 }
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.ts (1)

Line range hint 1-989: Consider extracting the error handling pattern into a utility function.

The error handling pattern is repeated across multiple methods. Consider creating a utility function to reduce duplication and improve maintainability.

private handleGrpcError(e: unknown, context: string): never {
  if (e instanceof InjectiveMetaRpc.GrpcWebError) {
    throw new GrpcUnaryRequestException(new Error(e.toString()), {
      code: grpcErrorCodeToErrorCode(e.code),
      context,
      contextModule: this.module,
    })
  }

  throw new GrpcUnaryRequestException(e as Error, {
    code: UnspecifiedErrorCode,
    context,
    contextModule: this.module,
  })
}

Usage example:

 try {
   const response = await this.retry<MitoApi.GetVaultResponse>(() =>
     this.client.GetVault(request),
   )
   return IndexerGrpcMitoTransformer.vaultResponseToVault(response)
 } catch (e: unknown) {
-  if (e instanceof InjectiveMetaRpc.GrpcWebError) {
-    throw new GrpcUnaryRequestException(new Error(e.toString()), {
-      code: grpcErrorCodeToErrorCode(e.code),
-      context: 'GetVault',
-      contextModule: this.module,
-    })
-  }
-
-  throw new GrpcUnaryRequestException(e as Error, {
-    code: UnspecifiedErrorCode,
-    context: 'GetVault',
-    contextModule: this.module,
-  })
+  this.handleGrpcError(e, 'GetVault')
 }
packages/networks/tsconfig.build.esm.json (1)

1-1: Consider documenting the dual module system strategy.

The transition to supporting both CommonJS (via commonjs+node) and ESM (via NodeNext) builds is a solid architectural choice. Consider adding documentation about:

  1. The rationale behind supporting both module systems
  2. How consumers should choose between CJS and ESM builds
  3. Any migration guides for downstream dependencies
packages/sdk-ts/src/utils/crypto.ts (2)

1-2: Remove commented-out import statement for cleaner codebase.

The commented-out import statement on line 1 is unnecessary and can be removed to keep the codebase clean.

Apply this diff:

-// import CryptoEs from 'crypto-es'

83-83: Simplify Buffer conversion in decompressPubKey function.

In line 83, since testBuffer is already a Buffer, using Buffer.from(testBuffer) is redundant. You can simplify the code by converting testBuffer directly to a hexadecimal string.

Apply this diff:

-    Buffer.from(testBuffer).toString('hex'),
+    testBuffer.toString('hex'),
packages/sdk-ts/src/utils/address.ts (1)

107-111: LGTM! Consider adding input validation.

The new utility functions are well-implemented and focused. However, consider adding input validation to ensure the input is a valid hex string.

 export const addHexPrefix = (hex: string) =>
+  hex && typeof hex === 'string' && /^[0-9a-fA-F]*$/.test(hex.replace('0x', '')) ?
   hex.startsWith('0x') ? hex : `0x${hex}`
+  : throw new Error('Invalid hex string')

 export const removeHexPrefix = (hex: string) =>
+  hex && typeof hex === 'string' && /^[0-9a-fA-F]*$/.test(hex.replace('0x', '')) ?
   hex.startsWith('0x') ? hex.slice(2) : hex
+  : throw new Error('Invalid hex string')
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/PrivateKey.ts (1)

254-256: Add documentation for unsupported operation.

Since private key wallets don't support account changes, consider adding a comment explaining why this operation is not implemented.

Apply this diff to improve documentation:

  async onAccountChange(
    _callback: (account: AccountAddress | string[]) => void,
  ): Promise<void> {
-    //
+    // Private key wallets don't support account changes as they are bound to a single key
  }
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1)

245-247: Consider standardizing the account change handling across wallet implementations.

The codebase shows inconsistencies in how different wallet strategies handle account changes:

  1. Some implementations are empty (PrivateKey)
  2. Some use incorrect event names (Ninji)
  3. All implementations only handle single accounts despite the new type supporting arrays

Consider:

  1. Creating an abstract base class method that enforces consistent implementation
  2. Documenting why some wallets support multiple accounts while others don't
  3. Adding migration notes since these files are in a deprecated directory
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (1)

26-29: Consider extracting common wallet functionality into a base class.

All wallet strategy implementations share similar patterns for:

  • Type assertions for ethereum.request calls
  • Error handling with specific wallet exceptions
  • Transaction receipt polling logic
  • Account and chain ID change event handling

Consider creating a base Ethereum wallet strategy class that implements these common patterns, reducing code duplication and ensuring consistent behavior across wallet implementations.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between da1934e and bb6740e.

📒 Files selected for processing (157)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/BitGet/index.ts (7 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Leap.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/Base.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts (7 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (8 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts (8 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/PrivateKey.ts (1 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/TrustWallet/index.ts (7 hunks)
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/WalletConnect.ts (1 hunks)
  • etc/replacements-ledger.js (0 hunks)
  • etc/replacements.js (0 hunks)
  • jest.config.js (2 hunks)
  • lerna.json (0 hunks)
  • package.json (5 hunks)
  • packages/exceptions/jest.config.js (1 hunks)
  • packages/exceptions/package.json (1 hunks)
  • packages/exceptions/src/exceptions/types/codes.ts (2 hunks)
  • packages/exceptions/tsconfig.build.esm.json (1 hunks)
  • packages/exceptions/tsconfig.build.json (1 hunks)
  • packages/networks/jest.config.js (1 hunks)
  • packages/networks/package.json (1 hunks)
  • packages/networks/src/chainInfos.ts (1 hunks)
  • packages/networks/src/endpoints.ts (4 hunks)
  • packages/networks/tsconfig.build.esm.json (1 hunks)
  • packages/networks/tsconfig.build.json (1 hunks)
  • packages/sdk-ts/jest.config.js (1 hunks)
  • packages/sdk-ts/package.json (2 hunks)
  • packages/sdk-ts/src/client/abacus/grpc/AbacusGrpcApi.ts (4 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts (4 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.ts (4 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthZApi.ts (4 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (9 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts (6 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts (12 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts (7 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcIbcApi.ts (3 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.ts (6 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcMintApi.ts (4 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcOracleApi.ts (2 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts (2 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts (7 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.ts (18 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcTendermintApi.ts (2 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (5 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmApi.ts (10 hunks)
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (3 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts (8 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.ts (9 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAuctionApi.ts (5 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.ts (7 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.ts (16 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (12 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.ts (3 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMetaApi.ts (4 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.ts (23 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts (4 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (3 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (11 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTradingApi.ts (3 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTransactionApi.ts (6 hunks)
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcWeb3GwApi.ts (2 hunks)
  • packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1 hunks)
  • packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.ts (11 hunks)
  • packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts (2 hunks)
  • packages/sdk-ts/src/core/modules/auction/msgs/MsgBid.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/bank/msgs/MsgSend.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawDelegatorReward.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawValidatorCommission.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelBinaryOptionsOrders.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelDerivativeOrders.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsMarketOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeLimitOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeMarketOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotLimitOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotMarketOrder.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgExternalTransfer.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgIncreasePositionMargin.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgWithdraw.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/feegrant/msgs/MsgGrantAllowance.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/feegrant/msgs/MsgRevokeAllowance.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/gov/msgs/MsgDeposit.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/gov/msgs/MsgVote.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/insurance/msgs/MsgCreateInsuranceFund.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/insurance/msgs/MsgUnderwrite.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgCreateNamespace.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgDeleteNamespace.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgRevokeNamespaceRoles.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespace.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespaceRoles.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateParams.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/staking/msgs/MsgCancelUnbondingDelegation.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/staking/msgs/MsgDelegate.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/staking/msgs/MsgEditValidator.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/staking/msgs/MsgUndelegate.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgBurn.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgChangeAdmin.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgCreateDenom.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgMint.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgSetDenomMetadata.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (2 hunks)
  • packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.spec.ts (1 hunks)
  • packages/sdk-ts/src/core/tx/eip712/eip712.spec.ts (1 hunks)
  • packages/sdk-ts/src/utils/address.ts (1 hunks)
  • packages/sdk-ts/src/utils/crypto.ts (3 hunks)
  • packages/sdk-ts/tsconfig.build.esm.json (1 hunks)
  • packages/sdk-ts/tsconfig.build.json (1 hunks)
  • packages/test-utils/CHANGELOG.md (0 hunks)
  • packages/test-utils/README.md (0 hunks)
  • packages/test-utils/package.json (0 hunks)
  • packages/test-utils/tsconfig.build.esm.json (0 hunks)
  • packages/test-utils/tsconfig.build.json (0 hunks)
  • packages/test-utils/tsconfig.json (0 hunks)
  • packages/ts-types/jest.config.js (1 hunks)
  • packages/ts-types/package.json (2 hunks)
  • packages/ts-types/tsconfig.build.esm.json (1 hunks)
  • packages/ts-types/tsconfig.build.json (1 hunks)
  • packages/utils/jest.config.js (1 hunks)
  • packages/utils/package.json (3 hunks)
  • packages/utils/src/classes/LocalStorage.ts (1 hunks)
  • packages/utils/src/helpers.ts (2 hunks)
  • packages/utils/src/test-utils/msgs.ts (2 hunks)
  • packages/utils/tsconfig.build.esm.json (1 hunks)
  • packages/utils/tsconfig.build.json (1 hunks)
  • packages/wallet-ts/.npmignore (0 hunks)
⛔ Files not processed due to max files limit (57)
  • packages/wallet-ts/LICENSE
  • packages/wallet-ts/jest.config.js
  • packages/wallets/wallet-base/package.json
  • packages/wallets/wallet-base/src/types/enums.ts
  • packages/wallets/wallet-base/src/types/provider.ts
  • packages/wallets/wallet-base/src/types/strategy.ts
  • packages/wallets/wallet-base/src/utils/wallet.ts
  • packages/wallets/wallet-base/tsconfig.build.esm.json
  • packages/wallets/wallet-base/tsconfig.build.json
  • packages/wallets/wallet-core/package.json
  • packages/wallets/wallet-core/src/broadcaster/MsgBroadcaster.ts
  • packages/wallets/wallet-core/tsconfig.build.esm.json
  • packages/wallets/wallet-core/tsconfig.build.json
  • packages/wallets/wallet-cosmos-strategy/package.json
  • packages/wallets/wallet-cosmos-strategy/tsconfig.build.esm.json
  • packages/wallets/wallet-cosmos-strategy/tsconfig.build.json
  • packages/wallets/wallet-cosmos/README.md
  • packages/wallets/wallet-cosmos/package.json
  • packages/wallets/wallet-cosmos/src/strategy/strategy.ts
  • packages/wallets/wallet-cosmos/tsconfig.build.esm.json
  • packages/wallets/wallet-cosmos/tsconfig.build.json
  • packages/wallets/wallet-cosmostation/README.md
  • packages/wallets/wallet-cosmostation/package.json
  • packages/wallets/wallet-cosmostation/tsconfig.build.esm.json
  • packages/wallets/wallet-cosmostation/tsconfig.build.json
  • packages/wallets/wallet-evm/README.md
  • packages/wallets/wallet-evm/package.json
  • packages/wallets/wallet-evm/src/strategy/strategy.ts
  • packages/wallets/wallet-evm/src/utils/index.ts
  • packages/wallets/wallet-evm/tsconfig.build.esm.json
  • packages/wallets/wallet-evm/tsconfig.build.json
  • packages/wallets/wallet-ledger/README.md
  • packages/wallets/wallet-ledger/package.json
  • packages/wallets/wallet-ledger/src/strategy/Ledger/Base.ts
  • packages/wallets/wallet-ledger/src/strategy/Ledger/hw/AccountManager.ts
  • packages/wallets/wallet-ledger/src/strategy/Ledger/hw/index.ts
  • packages/wallets/wallet-ledger/src/strategy/LedgerCosmos/hw/AccountManager.ts
  • packages/wallets/wallet-ledger/src/strategy/LedgerCosmos/hw/index.ts
  • packages/wallets/wallet-ledger/tsconfig.build.esm.json
  • packages/wallets/wallet-ledger/tsconfig.build.json
  • packages/wallets/wallet-magic/README.md
  • packages/wallets/wallet-magic/package.json
  • packages/wallets/wallet-magic/tsconfig.build.esm.json
  • packages/wallets/wallet-magic/tsconfig.build.json
  • packages/wallets/wallet-private-key/README.md
  • packages/wallets/wallet-private-key/package.json
  • packages/wallets/wallet-private-key/src/strategy/strategy.ts
  • packages/wallets/wallet-private-key/tsconfig.build.esm.json
  • packages/wallets/wallet-private-key/tsconfig.build.json
  • packages/wallets/wallet-strategy/package.json
  • packages/wallets/wallet-strategy/tsconfig.build.esm.json
  • packages/wallets/wallet-strategy/tsconfig.build.json
  • packages/wallets/wallet-trezor/README.md
  • packages/wallets/wallet-trezor/package.json
  • packages/wallets/wallet-trezor/src/strategy/hw/AccountManager.ts
  • packages/wallets/wallet-trezor/src/strategy/hw/index.ts
  • packages/wallets/wallet-trezor/src/strategy/strategy.ts
💤 Files with no reviewable changes (10)
  • packages/wallet-ts/.npmignore
  • packages/test-utils/README.md
  • lerna.json
  • packages/test-utils/CHANGELOG.md
  • packages/test-utils/tsconfig.build.esm.json
  • packages/test-utils/tsconfig.json
  • packages/test-utils/package.json
  • etc/replacements-ledger.js
  • packages/test-utils/tsconfig.build.json
  • etc/replacements.js
✅ Files skipped from review due to trivial changes (30)
  • packages/sdk-ts/src/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotLimitOrder.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.spec.ts
  • packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgBurn.spec.ts
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.spec.ts
  • packages/sdk-ts/src/core/modules/feegrant/msgs/MsgRevokeAllowance.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.spec.ts
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgRevokeNamespaceRoles.spec.ts
  • packages/sdk-ts/src/core/tx/eip712/eip712.spec.ts
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts
  • packages/sdk-ts/src/core/modules/bank/msgs/MsgSend.spec.ts
  • packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts
  • packages/sdk-ts/src/core/modules/permissions/msgs/MsgCreateNamespace.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.spec.ts
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.spec.ts
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.spec.ts
  • packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelDerivativeOrders.spec.ts
  • packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.spec.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.spec.ts
  • packages/sdk-ts/src/core/modules/insurance/msgs/MsgUnderwrite.spec.ts
  • packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.spec.ts
  • deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/Base.ts
  • packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.spec.ts
  • packages/utils/src/classes/LocalStorage.ts
  • packages/sdk-ts/src/core/modules/feegrant/msgs/MsgGrantAllowance.spec.ts
🧰 Additional context used
🪛 GitHub Actions: Publish canary branch
packages/exceptions/package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/networks/package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/utils/package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/sdk-ts/package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/ts-types/package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

package.json

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

🔇 Additional comments (124)
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)

3-3: LGTM: Import path updated as part of package deprecation.

The import path change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the PR objectives of deprecating packages.

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)

2-3: LGTM! Import path updated correctly.

The migration of mockFactory from test-utils to utils/test-utils aligns with the package deprecation objectives.

packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)

1-1: Verify consistent migration from test-utils package.

The import change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the package deprecation objective.

Let's verify that all imports from the deprecated package have been updated:

✅ Verification successful

Import migration successfully verified

The migration from @injectivelabs/test-utils to @injectivelabs/utils/test-utils has been consistently implemented across all test files. While the old package remains in dependency files (package.json, yarn.lock), this is expected during the transition period.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining imports from the deprecated package
rg "@injectivelabs/test-utils"

# Search for the new import pattern to confirm consistent migration
rg "@injectivelabs/utils/test-utils"

Length of output: 13554

packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts (1)

2-2: LGTM! Import path updated as part of package deprecation.

The change aligns with the PR objectives of deprecating packages, moving test utilities from @injectivelabs/test-utils to @injectivelabs/utils/test-utils.

packages/sdk-ts/src/core/modules/permissions/msgs/MsgDeleteNamespace.spec.ts (1)

3-3: LGTM! Consistent import path update.

The change follows the same pattern of moving test utilities to the new package location.

packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateParams.spec.ts (1)

3-3: LGTM! Import path updated consistently.

The change maintains consistency with other test files in updating the test utilities import path.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcOracleApi.ts (2)

3-4: LGTM! Enhanced error handling imports.

Added grpcErrorCodeToErrorCode for standardized error code conversion.


39-39: LGTM! Improved error code handling.

Updated to use grpcErrorCodeToErrorCode for consistent error code mapping across the SDK.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcTendermintApi.ts (2)

6-7: LGTM! Standardized error code handling.

The addition of grpcErrorCodeToErrorCode aligns with the refactoring goal of standardizing error handling across the SDK.


39-42: LGTM! Improved error code transformation.

The change from direct error code usage to grpcErrorCodeToErrorCode(e.code) ensures consistent error code handling across gRPC calls.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts (2)

3-5: LGTM! Consistent error handling imports.

The import changes maintain consistency with other gRPC API classes in the codebase.


42-45: LGTM! Standardized error transformation.

The implementation of grpcErrorCodeToErrorCode matches the pattern used in other gRPC API classes.

packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespaceRoles.spec.ts (1)

3-3: LGTM! Updated import path for deprecated package.

The change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the PR objective of deprecating packages and consolidating utilities.

packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawValidatorCommission.spec.ts (1)

2-2: LGTM! Consistent import path update.

The import path change maintains consistency with other spec files in moving away from the deprecated test-utils package.

packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespace.spec.ts (1)

3-3: LGTM! Import path updated correctly.

The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' aligns with the package deprecation objectives.

packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgChangeAdmin.spec.ts (1)

2-2: LGTM! Import path updated consistently.

The import path change maintains consistency with other files in the codebase.

packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawDelegatorReward.spec.ts (1)

2-2: LGTM! Import path updated systematically.

The import path change is consistent with the codebase-wide update pattern.

packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgMint.spec.ts (1)

3-3: LGTM! Import path updated as part of the package deprecation.

The import path change aligns with the systematic update across the codebase.

Let's verify that all test files have been updated consistently:

✅ Verification successful

Import path migration verified successfully

All test files in the codebase are consistently using the new import path @injectivelabs/utils/test-utils, and no occurrences of the old import path @injectivelabs/test-utils were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any remaining old import paths
rg -l "@injectivelabs/test-utils" "packages/sdk-ts/src/**/*.spec.ts"

# Verify new import paths are used consistently
rg -l "@injectivelabs/utils/test-utils" "packages/sdk-ts/src/**/*.spec.ts"

Length of output: 289


Script:

#!/bin/bash
# Find all spec files first
echo "=== Spec files ==="
fd "\.spec\.ts$" packages/sdk-ts/src/

echo -e "\n=== Files with old import path ==="
fd "\.spec\.ts$" packages/sdk-ts/src/ -x rg -l "@injectivelabs/test-utils" {}

echo -e "\n=== Files with new import path ==="
fd "\.spec\.ts$" packages/sdk-ts/src/ -x rg -l "@injectivelabs/utils/test-utils" {}

Length of output: 11407

packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts (1)

3-3: LGTM: Import path updated as part of package deprecation.

The change aligns with the PR objective of deprecating the test-utils package.

packages/sdk-ts/src/core/modules/gov/msgs/MsgVote.spec.ts (1)

2-2: LGTM: Import path updated consistently.

The change maintains consistency with other test files in the refactoring effort.

packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgCreateDenom.spec.ts (1)

2-2: LGTM: Import path updated consistently.

The change aligns with the package deprecation effort. Since this test relies heavily on mockFactory for multiple values, let's verify the functionality remains identical.

✅ Verification successful

Verified: mockFactory functionality remains identical after import path change

The mockFactory is consistently implemented in a single location and used uniformly across test files, maintaining the same mock values and functionality.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify mockFactory exports and functionality remain identical
# between old and new packages

# Check if both packages export the same mock factory interface
rg -A 5 "export.*mockFactory" 

Length of output: 431


Script:

#!/bin/bash
# Get the full implementation of mockFactory and related mock values
ast-grep --pattern 'export const mockFactory = {
  $$$
}'

# Search for any other mockFactory exports or implementations
rg -g '!*.{log,lock}' -A 10 'mockFactory'

# Check the actual mock value declarations
rg -g '!*.{log,lock}' '(ethereumAddress|injectiveAddress|validatorAddress) ='

Length of output: 66865

packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts (1)

2-2: LGTM: Import path updated consistently.

The change maintains consistency with the package deprecation effort.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (2)

Line range hint 1-24: LGTM! Well-structured and comprehensive test implementation.

The test suite thoroughly covers all necessary message formats (proto, amino, EIP-712, web3) and follows consistent patterns across files. The import path change doesn't affect the test logic.

Also applies to: 25-67


3-3: Verify the new test-utils import path.

The import path has been updated as part of deprecating the test-utils package. Let's verify the new location and implementation.

✅ Verification successful

The test-utils import path is correctly implemented.

The import path @injectivelabs/utils/test-utils is properly mapped to its implementation in packages/utils/src/test-utils/ and is being used consistently across all test files in the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the new test-utils implementation and check for potential breaking changes

# Check if the new path exists
fd -t f "test-utils" packages/sdk-ts/

# Check the implementation differences between old and new locations
rg -A 5 "export.*mockFactory" packages/sdk-ts/

Length of output: 86


Script:

#!/bin/bash
# Broader search for test-utils and mockFactory
rg -l "test-utils" .
rg -l "mockFactory" .

# Check contents of utils directory
fd . packages/sdk-ts/src/utils -t f

# Search for mockFactory usage
rg "mockFactory" -A 3

Length of output: 67266


Script:

#!/bin/bash
# Check mockFactory implementation
cat packages/utils/src/test-utils/mocks/index.ts

# Verify no other test-utils implementations exist
fd -t f "test-utils.ts" .
fd -t f "test-utils.js" .

# Check if there are any references to old paths
rg "from ['\"]((?!@injectivelabs/utils/test-utils).)*test-utils['\"]"

Length of output: 4148


Script:

#!/bin/bash
# Search for test-utils imports with simpler pattern
rg "from.*test-utils['\"]" .
rg "require.*test-utils['\"]" .

Length of output: 9280

packages/sdk-ts/src/core/modules/exchange/msgs/MsgWithdraw.spec.ts (1)

3-3: Same change as in other files.

The import path update follows the same pattern as other files.

packages/sdk-ts/src/core/modules/auction/msgs/MsgBid.spec.ts (1)

2-2: Same change as in other files.

The import path update follows the same pattern as other files.

packages/sdk-ts/src/core/modules/staking/msgs/MsgDelegate.spec.ts (1)

3-3: Same change as in other files.

The import path update follows the same pattern as other files.

packages/sdk-ts/src/core/modules/staking/msgs/MsgUndelegate.spec.ts (1)

3-3: LGTM! Import path updated as part of test-utils deprecation.

The change aligns with the PR objective of deprecating the standalone test-utils package.

Let's verify the consistency of this change across the codebase:

✅ Verification successful

Import path migration is consistent across the codebase

All spec files in the sdk-ts package consistently use the new import path @injectivelabs/utils/test-utils. While the package.json still lists the old package as a dependency, this might be intentional for backward compatibility or pending cleanup in a separate PR.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify no references to the old package remain
rg "@injectivelabs/test-utils"

# Verify all spec files use the new import path
rg -t typescript "from '@injectivelabs/utils/test-utils'" "**/*.spec.ts"

Length of output: 4555


Script:

#!/bin/bash
# Search for old import pattern in spec files
rg "from '@injectivelabs/test-utils'" "**/*.spec.ts"

# Search for new import pattern in spec files
rg "from '@injectivelabs/utils/test-utils'" "**/*.spec.ts"

# Check package.json files for test-utils related entries
fd "package.json" --exec grep -l "test-utils"

Length of output: 338


Script:

#!/bin/bash
# Search for old import pattern in sdk-ts spec files
rg "from '@injectivelabs/test-utils'" packages/sdk-ts/src --type ts

# Search for new import pattern in sdk-ts spec files
rg "from '@injectivelabs/utils/test-utils'" packages/sdk-ts/src --type ts

# Check content of relevant package.json files
cat packages/utils/package.json | grep -A 5 -B 5 "test-utils"
cat packages/sdk-ts/package.json | grep -A 5 -B 5 "test-utils"

Length of output: 10698

packages/sdk-ts/src/core/modules/gov/msgs/MsgDeposit.spec.ts (1)

3-3: LGTM! Import path updated consistently.

The change maintains consistency with other spec files in the migration.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts (1)

2-2: LGTM! Import path updated consistently.

The change follows the established pattern of migrating from test-utils to utils/test-utils.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (1)

2-2: LGTM! Import path updated consistently.

The change maintains consistency with the test-utils deprecation effort.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)

3-4: LGTM! Error handling standardization.

The addition of grpcErrorCodeToErrorCode improves error code consistency across the SDK.

packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts (1)

3-3: LGTM! Consistent with other test files.

The import path change is part of the broader package deprecation effort.

packages/sdk-ts/src/core/modules/staking/msgs/MsgCancelUnbondingDelegation.spec.ts (1)

3-3: LGTM! Consistent with other test files.

The import path change is part of the broader package deprecation effort.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgIncreasePositionMargin.spec.ts (1)

2-2: Verify the new test-utils package.

The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is part of the package deprecation effort. Let's verify the availability and version of the new package location.

✅ Verification successful

Import path change is correct and properly implemented

The new import path @injectivelabs/utils/test-utils is consistently used across 60+ spec files in the sdk-ts package, confirming this is part of a coordinated package deprecation effort. The package is properly declared in the project's dependencies.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if the new test-utils location exists and verify its exports
fd --type f "test-utils" packages/utils

Length of output: 39


Script:

#!/bin/bash
# Search for test-utils files across the repo
fd --type f "test-utils"

# Search for similar imports
rg "@injectivelabs/utils/test-utils"

# Check old location imports
rg "@injectivelabs/test-utils"

Length of output: 13579

packages/sdk-ts/src/core/modules/staking/msgs/MsgEditValidator.spec.ts (1)

2-2: LGTM! Import path updated consistently.

The import statement has been updated to use the new package location, maintaining consistency with other test files.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelBinaryOptionsOrders.spec.ts (1)

2-2: LGTM! Import path updated consistently.

The import statement has been updated to use the new package location, maintaining consistency with other test files.

packages/sdk-ts/src/core/modules/insurance/msgs/MsgCreateInsuranceFund.spec.ts (1)

3-3: LGTM! Import path updated consistently.

The import statement has been updated to use the new package location, maintaining consistency with other test files.

packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgSetDenomMetadata.spec.ts (1)

2-2: LGTM! Import path updated as part of package deprecation.

The change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the package deprecation objectives.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcIbcApi.ts (2)

3-4: LGTM! Enhanced error handling with standardized error code conversion.

Added grpcErrorCodeToErrorCode import for consistent error code handling across the SDK.


44-44: Improved error handling with standardized error code conversion.

The use of grpcErrorCodeToErrorCode ensures consistent error code handling across gRPC exceptions.

Also applies to: 78-78

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.ts (2)

3-4: LGTM! Enhanced error handling with standardized error code conversion.

Added grpcErrorCodeToErrorCode import for consistent error code handling across the SDK.


60-60: Improved error handling with standardized error code conversion.

The use of grpcErrorCodeToErrorCode ensures consistent error code handling across gRPC exceptions.

Also applies to: 88-88

packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts (2)

2-2: LGTM! Import path updated as part of package deprecation.

The change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the package deprecation objectives.


Line range hint 28-28: Address skipped test suite.

The test suite is marked with TODO and skipped. Consider implementing the missing tests or document the reason for skipping.

Would you like me to help implement the missing tests or document the reason for skipping?

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMetaApi.ts (1)

3-4: LGTM! Consistent error handling implementation.

The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves code consistency and error reporting.

Also applies to: 38-38, 64-64, 92-92

packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.ts (1)

2-2: LGTM! Successful migration from deprecated package.

The import path update from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the PR objective of deprecating packages.

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (1)

3-4: LGTM! Standardized error handling implementation.

The error handling has been properly standardized using grpcErrorCodeToErrorCode.

Also applies to: 54-54, 95-95

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotMarketOrder.spec.ts (1)

2-2: LGTM! Import path updated as part of package deprecation.

The change aligns with the PR objective of deprecating the test-utils package by moving the mockFactory utility to @injectivelabs/utils/test-utils.

Let's verify the new import path exists:

✅ Verification successful

Import path verified and correctly updated

The mockFactory utility is properly located at packages/utils/src/test-utils and the new import path @injectivelabs/utils/test-utils is correctly used across the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify the new location of mockFactory
fd -e ts -e js "mockFactory" packages/utils/test-utils

Length of output: 167


Script:

#!/bin/bash
# First, find the utils package directory
fd -t d "utils$" packages

# Then, search for mockFactory in all TypeScript/JavaScript files
rg -t ts -t js "mockFactory" packages

Length of output: 28138

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAuctionApi.ts (2)

3-4: LGTM! Import added for standardized error handling.

The addition of grpcErrorCodeToErrorCode aligns with the PR objective of standardizing error code processing.


48-48: LGTM! Standardized error code handling implemented.

Error handling has been updated to use grpcErrorCodeToErrorCode consistently across all methods, improving error code standardization.

Let's verify this pattern is consistently applied across other gRPC API files:

Also applies to: 74-74, 101-101

✅ Verification successful

Standardized error handling verified across all gRPC APIs

The grpcErrorCodeToErrorCode implementation is consistently applied across all gRPC API files in the codebase, including Chain, Indexer, OLP, and Abacus APIs, confirming standardized error handling throughout the system.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for consistent usage of grpcErrorCodeToErrorCode in gRPC API files
rg "grpcErrorCodeToErrorCode\(e\.code\)" packages/sdk-ts/src/client/

Length of output: 22889

packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts (2)

3-4: LGTM! Import added for standardized error handling.

The addition of grpcErrorCodeToErrorCode aligns with the PR objective of standardizing error code processing.


43-43: LGTM! Standardized error code handling implemented.

Error handling has been updated to use grpcErrorCodeToErrorCode consistently across all methods, maintaining consistency with other gRPC API implementations.

Also applies to: 73-73, 103-103

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeLimitOrder.spec.ts (1)

2-2: LGTM! Import path updated as part of package deprecation.

The change aligns with the PR objective of deprecating the test-utils package by moving the mockFactory utility to @injectivelabs/utils/test-utils.

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeMarketOrder.spec.ts (1)

2-2: Verify package deprecation impact.

The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is part of the package deprecation effort.

✅ Verification successful

Import path change is properly implemented.

The functionality from @injectivelabs/test-utils has been successfully migrated to @injectivelabs/utils/test-utils with all necessary test utilities, mock data, and helper functions intact. The change is part of a planned package reorganization.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are any remaining references to the old package
rg "@injectivelabs/test-utils"

# Check if there's a migration guide or breaking change notice
fd "MIGRATION|BREAKING|CHANGELOG" -e md

Length of output: 5226


Script:

#!/bin/bash
# Check if the new module exists
fd "test-utils" packages/utils

# Check for migration notes or breaking changes in relevant changelogs
cat packages/utils/CHANGELOG.md
cat packages/sdk-ts/CHANGELOG.md

Length of output: 65696


Script:

#!/bin/bash
# Check content of test-utils directory
ls -la packages/utils/src/test-utils/
cat packages/utils/src/test-utils/index.ts 2>/dev/null || true

Length of output: 424


Script:

#!/bin/bash
# Check content of mocks and msgs
ls -la packages/utils/src/test-utils/mocks/
cat packages/utils/src/test-utils/mocks/index.ts 2>/dev/null || true
cat packages/utils/src/test-utils/msgs.ts 2>/dev/null || true

Length of output: 6487

packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.ts (1)

3-4: LGTM! Improved error handling consistency.

The use of grpcErrorCodeToErrorCode standardizes error code processing across gRPC APIs, which is a good practice for maintaining consistent error handling throughout the codebase.

Also applies to: 44-44, 73-73, 105-105

packages/sdk-ts/src/client/chain/grpc/ChainGrpcMintApi.ts (1)

3-4: LGTM! Consistent with error handling improvements.

The changes follow the same pattern as in ChainGrpcAuthApi.ts, maintaining consistency in error handling across gRPC APIs.

Also applies to: 45-45, 76-76, 107-107

packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsMarketOrder.spec.ts (1)

2-2: LGTM! Consistent with package deprecation changes.

The import path update follows the same pattern as in MsgCreateDerivativeMarketOrder.spec.ts.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.spec.ts (1)

4-4: Verify the new test-utils import path.

The import path has been updated as part of deprecating the test-utils package. Let's verify that the new path is correctly configured.

✅ Verification successful

Import path for mockFactory is correctly configured

The mockFactory is properly exported from packages/utils/src/test-utils/mocks/index.ts and contains all the necessary mock data and utilities.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify the new test-utils module exists and is exported correctly
rg -g '*.{js,ts}' -l "export.*mockFactory" packages/utils/

Length of output: 105


Script:

#!/bin/bash
# Check the actual export configuration
cat packages/utils/src/test-utils/mocks/index.ts

Length of output: 3744

packages/sdk-ts/src/client/abacus/grpc/AbacusGrpcApi.ts (1)

4-4: LGTM! Standardized error handling implementation.

The addition of grpcErrorCodeToErrorCode improves error handling consistency across the codebase by standardizing how gRPC error codes are processed.

Also applies to: 39-39, 75-75, 111-111

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTradingApi.ts (1)

3-4: LGTM! Consistent error handling implementation.

The standardized error handling has been correctly implemented across both methods, maintaining consistency with the rest of the codebase.

Also applies to: 39-39, 158-158

packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthZApi.ts (1)

3-3: LGTM! Consistent error handling improvement.

The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves consistency and provides better error reporting.

Also applies to: 70-70, 109-109, 148-148

packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (1)

3-4: LGTM! Consistent error handling improvement.

The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves consistency and provides better error reporting.

Also applies to: 45-45, 108-108, 138-138

packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.ts (1)

3-4: LGTM! Consistent error handling improvement.

The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves consistency and provides better error reporting.

Also applies to: 43-43, 73-73, 105-105, 144-144, 183-183

packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.spec.ts (1)

3-3: LGTM! Updated import path as part of package deprecation.

The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' aligns with the package deprecation objective.

packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts (1)

3-4: LGTM! Consistent error handling implementation.

The changes standardize error handling by using grpcErrorCodeToErrorCode across all methods, ensuring uniform error code processing throughout the API.

Also applies to: 46-46, 83-83, 111-111, 138-138, 175-175, 205-205

packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts (1)

3-4: LGTM! Consistent error handling with proper NoThrow variants.

The changes standardize error handling while preserving special error cases in NoThrow variants, demonstrating a thoughtful implementation that balances consistency with specific requirements.

Also applies to: 43-43, 82-82, 128-128, 160-160, 196-196

packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts (1)

3-4: LGTM! Consistent error handling across governance operations.

The changes implement standardized error handling across all governance-related methods, ensuring uniform error code processing throughout the API.

Also applies to: 52-52, 93-93, 121-121, 161-161, 200-200, 228-228

packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (1)

7-10: LGTM! Consistent error handling in transaction operations.

The changes implement standardized error handling using grpcErrorCodeToErrorCode, aligning with the SDK-wide improvements.

Also applies to: 80-80

packages/networks/src/endpoints.ts (1)

49-49: LGTM! Consistent endpoint updates across network configurations.

The changes correctly update the explorer endpoints to use the dedicated explorer subdomain, maintaining consistency across different network environments.

Also applies to: 116-116, 146-146, 176-176

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.ts (1)

3-3: LGTM! Standardized error handling with grpcErrorCodeToErrorCode.

The changes consistently apply the error code transformation across all methods, improving error handling standardization.

Also applies to: 75-75, 134-134, 186-186, 234-234, 272-272, 331-331

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts (1)

4-4: LGTM! Consistent error handling improvements.

The changes properly implement the standardized error code transformation across all methods, maintaining consistency with other API modules.

Also applies to: 60-60, 89-89, 120-120, 149-149, 212-212, 257-257, 291-291

packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (1)

3-4: LGTM! Standardized error handling in chain API.

The changes successfully implement the consistent error code transformation pattern across all bank API methods, aligning with the broader refactoring effort.

Also applies to: 49-49, 85-85, 120-120, 152-152, 188-188, 222-222, 251-251, 288-288

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.ts (1)

3-3: Standardized error code handling improves consistency.

The introduction of grpcErrorCodeToErrorCode and its consistent application across all error handling blocks enhances error code standardization. This change ensures uniform error code translation across the entire module.

Let's verify the error code mapping implementation:

Also applies to: 50-50, 87-87, 124-124, 174-174, 224-224, 272-272, 320-320, 367-367

✅ Verification successful

Error code standardization verified across all GRPC APIs

The grpcErrorCodeToErrorCode implementation ensures consistent error code translation throughout the codebase, with uniform usage across all GRPC API error handling blocks.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the grpcErrorCodeToErrorCode implementation
# and its usage across the codebase

# Check the implementation
rg -A 5 "export const grpcErrorCodeToErrorCode" --type ts

# Verify consistent usage
rg "grpcErrorCodeToErrorCode\(.*\.code\)" --type ts

Length of output: 23472

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTransactionApi.ts (1)

103-103: Consistent error handling in deprecated class.

While the class is deprecated, the error handling improvements maintain consistency with the rest of the codebase. This is good practice during the deprecation period.

Also applies to: 179-179, 248-248, 304-304, 328-328

packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmApi.ts (1)

3-4: Standardized error handling in WASM operations.

The implementation of grpcErrorCodeToErrorCode across all WASM-related operations ensures consistent error handling. This standardization improves error reporting reliability across contract interactions.

Also applies to: 59-59, 102-102, 139-139, 170-170, 209-209, 242-242, 276-276, 306-306, 346-346

packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.ts (1)

2-4: Standardized error handling with preserved module context.

The implementation maintains module-specific error context while standardizing error code handling through grpcErrorCodeToErrorCode. This approach ensures consistent error handling while preserving important module-specific information.

Also applies to: 40-40, 69-69, 110-110, 148-148, 192-192, 233-233, 280-280, 327-327, 363-363, 406-406

packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts (1)

3-4: Consistent error handling implementation looks good!

The standardization of error code handling using grpcErrorCodeToErrorCode across all methods improves error reporting consistency and maintainability.

Also applies to: 43-43, 71-71, 101-101, 134-134, 164-164, 194-194, 231-231, 258-258, 288-288, 320-320, 352-352

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)

3-4: Error handling standardization looks good!

The consistent use of grpcErrorCodeToErrorCode across all methods improves error reporting reliability.

Also applies to: 39-39, 114-114, 145-145, 176-176, 231-231, 286-286, 344-344, 372-372, 452-452, 531-531, 559-559

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (1)

3-4: Error handling standardization looks good!

The consistent use of grpcErrorCodeToErrorCode across all methods enhances error reporting reliability.

Also applies to: 70-70, 99-99, 185-185, 293-293, 410-410, 461-461, 525-525, 563-563, 594-594, 649-649

packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.ts (1)

3-4: Error handling standardization and NoThrow variants look good!

The consistent use of grpcErrorCodeToErrorCode across all methods and proper handling of "does not exist" cases in NoThrow variants improve error handling reliability.

Also applies to: 44-44, 71-71, 106-106, 135-135, 179-179, 227-227, 271-271, 319-319, 357-357, 401-401, 449-449, 493-493, 541-541, 585-585, 633-633, 676-676, 723-723

packages/exceptions/src/exceptions/types/codes.ts (1)

3-21: LGTM! Well-structured gRPC error code enumeration.

The enum provides a comprehensive set of standard gRPC error codes with clear, descriptive names.

packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.ts (1)

Line range hint 1-964: Apply the same error handling utility pattern here.

Similar to IndexerGrpcMitoApi.ts, consider extracting the repeated error handling pattern into a utility function.

packages/utils/tsconfig.build.json (1)

6-7: LGTM! Proper configuration for CommonJS build.

The configuration correctly sets up CommonJS module compilation with appropriate module resolution strategy. This aligns with the dual CJS/ESM build approach.

Also applies to: 10-11

packages/utils/tsconfig.build.esm.json (1)

4-4: Verify package.json configuration for NodeNext compatibility.

The switch to NodeNext module system is good for modern Node.js compatibility. However, this requires proper configuration in package.json to support dual CJS/ESM builds.

Run this script to verify the package.json configuration:

Also applies to: 10-10

✅ Verification successful

✓ Package.json exports field is correctly configured for NodeNext

The package.json has proper conditional exports supporting both ESM and CommonJS, with correct type definitions and module paths. The configuration aligns well with the NodeNext module system.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if package.json is properly configured for dual CJS/ESM builds
# Expected: Should find "exports" field with proper conditional exports

# Check package.json in utils package
echo "Checking packages/utils/package.json:"
jq '.exports' packages/utils/package.json

# Verify import/require conditions
jq '.exports | select(. != null) | .. | .import? // .require?' packages/utils/package.json

Length of output: 1621

packages/sdk-ts/tsconfig.build.esm.json (1)

4-4: Verify dependencies compatibility with NodeNext.

The NodeNext configuration is consistent with other packages. However, as this is the main SDK package, we should verify that all dependencies support ESM imports.

Also applies to: 10-10

✅ Verification successful

Dependencies are compatible with NodeNext module resolution

The key dependencies in the SDK package demonstrate proper ESM support through exports fields or known ESM compatibility. The @InjectiveLabs ecosystem packages and core blockchain libraries all support dual CJS/ESM builds, making them fully compatible with NodeNext module resolution.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if dependencies in package.json support ESM
# Expected: Dependencies should have "exports" field or "type": "module"

# Get all dependencies
echo "Checking ESM support in dependencies:"
jq '.dependencies' packages/sdk-ts/package.json | 
  jq -r 'keys[]' |
  while read pkg; do
    if [ ! -z "$pkg" ]; then
      echo "Checking $pkg:"
      npm view $pkg exports --json 2>/dev/null || echo "No exports field"
    fi
  done

Length of output: 15027

packages/networks/tsconfig.build.json (1)

5-6: LGTM! Consistent with other packages.

The CommonJS build configuration maintains consistency with other packages in the monorepo.

Also applies to: 10-11

packages/ts-types/tsconfig.build.json (1)

6-7: LGTM! Proper setup for type definitions.

The CommonJS configuration is consistent with other packages and appropriate for generating type definitions.

Also applies to: 10-11

packages/sdk-ts/tsconfig.build.json (1)

5-6: LGTM! Appropriate module configuration for CommonJS build.

The addition of "module": "commonjs" and "moduleResolution": "node" is correct for the CommonJS build configuration.

packages/ts-types/tsconfig.build.esm.json (1)

4-4: LGTM! Verify package.json type field alignment.

The transition to "NodeNext" for both module and moduleResolution is appropriate for modern Node.js environments.

Please ensure this aligns with the package.json configuration:

Also applies to: 10-10

✅ Verification successful

Configuration alignment verified ✓

The package.json "type": "module" field correctly aligns with the tsconfig's "module": "NodeNext" setting for ESM output.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if package.json has the correct type field for ESM
jq -r '.type // empty' packages/ts-types/package.json

Length of output: 62

packages/exceptions/tsconfig.build.json (1)

5-6: LGTM! Consistent with other packages.

The CommonJS module configuration matches the pattern established in other packages.

packages/exceptions/tsconfig.build.esm.json (1)

4-4: LGTM! Verify package.json type field alignment.

The NodeNext configuration is appropriate and consistent with other packages.

Please ensure this aligns with the package.json configuration:

Also applies to: 10-10

✅ Verification successful

Configuration verified: package.json and tsconfig.build.esm.json are properly aligned for ESM

The package.json "type": "module" field correctly aligns with the "module": "NodeNext" TypeScript configuration for ES modules support.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if package.json has the correct type field for ESM
jq -r '.type // empty' packages/exceptions/package.json

Length of output: 64

packages/networks/tsconfig.build.esm.json (1)

4-4: LGTM! Verify package.json type field alignment.

The NodeNext configuration is appropriate and consistent with other packages.

Please ensure this aligns with the package.json configuration:

Also applies to: 10-10

✅ Verification successful

Configuration verified: package.json and tsconfig.build.esm.json are correctly aligned

The package.json "type": "module" field is properly set for ESM output, matching the NodeNext module configuration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if package.json has the correct type field for ESM
jq -r '.type // empty' packages/networks/package.json

Length of output: 62

packages/ts-types/jest.config.js (1)

Line range hint 1-9: Verify ESM configuration compatibility.

The migration to ESM looks good, but let's ensure all dependencies are ESM-compatible.

Run this script to verify the configuration:

✅ Verification successful

ESM configuration is properly set up

The configuration is correctly set up for ESM:

  • Root Jest config uses ESM presets and transforms
  • TypeScript ESM config exists with proper module settings
  • Base config import path is correct
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if base config and referenced TypeScript config exist and are ESM compatible
echo "Checking base Jest config..."
cat ../../jest.config.js

echo -e "\nChecking TypeScript ESM config..."
cat tsconfig.build.esm.json

echo -e "\nChecking package.json for type:module..."
cat package.json | jq '.type'

Length of output: 447


Script:

#!/bin/bash
# Search for Jest and TypeScript config files
echo "Searching for Jest config files..."
fd -e js -e cjs -e mjs "jest.config"

echo -e "\nSearching for TypeScript config files..."
fd "tsconfig"

echo -e "\nChecking current directory structure..."
pwd && ls -la

Length of output: 5943


Script:

#!/bin/bash
echo "Checking root Jest config..."
cat jest.config.js

echo -e "\nChecking ts-types TypeScript ESM config..."
cat packages/ts-types/tsconfig.build.esm.json

echo -e "\nChecking ts-types package.json..."
cat packages/ts-types/package.json | jq '{type,module,exports,main}'

Length of output: 7703

packages/sdk-ts/jest.config.js (1)

Line range hint 1-9: Same ESM migration pattern as ts-types package.

The changes are identical to those in packages/ts-types/jest.config.js.

packages/networks/jest.config.js (1)

Line range hint 1-9: Same ESM migration pattern as other packages.

The changes are identical to those in other Jest config files.

packages/utils/src/test-utils/msgs.ts (3)

1-2: Verify all BigNumber imports are consistently updated.

The change from external BigNumber to local BigNumberInBase is good, but let's ensure consistency across the codebase.

✅ Verification successful

BigNumber import change is consistent with codebase patterns

The change to use local BigNumberInBase import in msgs.ts follows the established pattern within the utils package, where implementation files use local imports from the classes directory.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any remaining BigNumber imports from @injectivelabs/utils
echo "Checking for old BigNumber imports..."
rg "import.*BigNumber.*from.*@injectivelabs/utils"

echo -e "\nChecking for new BigNumberInBase usage..."
rg "import.*BigNumberInBase.*from"

Length of output: 7351


75-78: Verify BigNumberInBase calculation equivalence.

The amount calculation using BigNumberInBase should produce the same results as the previous BigNumber implementation.

✅ Verification successful

BigNumberInBase calculation verified as correct

The gas amount calculation using BigNumberInBase follows the established pattern used throughout the codebase for gas fee calculations and maintains numerical precision as expected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for similar calculations in tests or documentation
rg "BigNumber.*times.*DEFAULT_GAS_PRICE" -A 2

Length of output: 47


Script:

#!/bin/bash
# Search for BigNumberInBase usage patterns
ast-grep --pattern 'new BigNumberInBase($$$)'

# Search for gas calculation tests
rg -t ts "describe.*gas" -A 5

# Search for BigNumber usage (both types)
rg "BigNumber(InBase)?" -A 2

Length of output: 66499


Line range hint 1-99: Consider deprecation impact of test-utils package.

According to the PR title, test-utils is being deprecated. This file might need to be moved or removed.

packages/utils/src/helpers.ts (1)

80-82: LGTM! Consistent use of BigNumberInBase.

The transition to BigNumberInBase for gas calculations improves consistency in number handling across the codebase.

Also applies to: 115-116, 122-124, 127-127

packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts (2)

2-2: LGTM! ESM-compliant import path.

The .js extension in the import path aligns with ESM requirements.


131-141: LGTM! Improved signature verification test.

The test now explicitly verifies signatures from both ethers and private key implementations, providing better coverage and clarity.

jest.config.js (2)

185-188: LGTM! Necessary configuration for ESM module.

The transformIgnorePatterns configuration correctly allows transformation of the @noble/secp256k1 ESM module.


90-90: Verify if the crypto-es mapping is needed.

The commented mapping suggests uncertainty. Please verify if this mapping is required for the tests to pass.

✅ Verification successful

The crypto-es mapping can be safely removed

The codebase has been updated to use crypto-js directly instead of crypto-es, as evidenced by the imports in packages/sdk-ts/src/utils/crypto.ts. The commented mapping in jest.config.js is no longer needed and can be removed.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if crypto-es is imported anywhere in the codebase
rg "from ['\"](crypto-es|crypto-js)['\"]" -t ts

Length of output: 194

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (1)

245-245: Consider updating implementation to match new type signature.

The callback type now supports string[] but the implementation only passes a single account. Consider updating the implementation to potentially handle multiple accounts if that's the intended use case.

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Leap.ts (1)

247-247: Implementation looks good!

The type signature update is consistent with other wallet strategies while maintaining the correct implementation for Leap wallet's single-account model.

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1)

247-247: Implementation looks good!

The type signature update is consistent with other wallet strategies while maintaining the correct implementation for Keplr wallet's single-account model.

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/BitGet/index.ts (1)

67-67: LGTM! Type safety improvements look good.

The changes enhance type safety through explicit type assertions and broaden the callback parameter type to handle both single and multiple account changes.

Also applies to: 96-96, 152-152, 207-207, 221-221, 239-239, 278-278

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts (2)

242-242: Add maximum retry attempts to prevent infinite recursion.

Similar to TrustWallet, the transactionReceiptRetry function needs a maximum retry limit to prevent infinite recursion.


224-224: Fix incorrect Promise type assertion.

The type assertion as Promise<string> is incorrect as ethereum.request already returns a Promise.

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (2)

239-242: Add maximum retry attempts to prevent infinite recursion.

The transactionReceiptRetry function needs a maximum retry limit to prevent infinite recursion.


224-224: Fix incorrect Promise type assertion.

The type assertion as Promise<string> is incorrect as ethereum.request already returns a Promise.

deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts (3)

26-29: LGTM! Class declaration formatting improves readability.

The multi-line class declaration with separate lines for extends and implements improves code readability.


70-72: Type assertions enhance type safety.

The explicit type assertions for method return types improve type safety and make the code more maintainable.

Also applies to: 98-101, 154-157, 212-212, 226-226, 241-244


283-283: Verify the impact of the callback type change.

The callback type has been updated to accept either AccountAddress or string[]. While this provides more flexibility, ensure that consumers of this API are prepared to handle both types.

✅ Verification successful

Callback type change has been properly propagated across the codebase

The callback type change has been consistently implemented across all active wallet strategies. The only exceptions are in deprecated packages which are no longer maintained.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usages of onAccountChange to verify consumers can handle the new type
rg -A 3 "onAccountChange\(" --type ts

Length of output: 8111

packages/ts-types/package.json (3)

7-7: LGTM! ESM migration.

The addition of "type": "module" aligns with the migration to ECMAScript modules.

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]


58-60: LGTM! Correct dependency categorization.

Moving shx to devDependencies is appropriate as it's only used during development/build.

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]


Line range hint 1-63: Address pipeline warnings.

The build pipeline reports missing peer dependencies:

  1. Missing @babel/core
  2. Incorrect peer dependency for typedoc-monorepo-link-types
🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/exceptions/package.json (1)

7-7: LGTM! Consistent ESM migration.

The addition of "type": "module" is consistent with the ESM migration across packages.

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/networks/package.json (1)

6-6: Verify ESM transition impact on existing consumers.

While adding "type": "module" aligns with the ESM transition, ensure that CommonJS consumers are not affected. The dual export configuration looks correct, but consider:

  1. Testing the package in both ESM and CommonJS environments
  2. Documenting the change in the changelog
  3. Potentially bumping the major version if this is a breaking change
✅ Verification successful

ESM transition is properly configured and safe

The package maintains full CommonJS compatibility through:

  • Dual CJS/ESM builds with correct configuration
  • Proper exports field routing
  • Format-specific package.json stubs in dist directories
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for direct CommonJS require statements that might break
rg "require\(['\"]@injectivelabs/networks['\"]" -A 5

Length of output: 58


Script:

#!/bin/bash
# Check package.json exports configuration
cat packages/networks/package.json

# Look for .cjs files that might be affected
fd '\.cjs$' packages/networks/

# Check for any require statements within the package
rg "require\(" packages/networks/

Length of output: 2388


Script:

#!/bin/bash
# Check tsconfig files to verify dual-format build setup
cat packages/networks/tsconfig.build.json
cat packages/networks/tsconfig.build.esm.json

# Check package.json stubs that are copied during build
cat etc/stub/package.json.stub
cat etc/stub/package.esm.json.stub

Length of output: 899

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/utils/package.json (2)

84-87: Good: Improved dependency organization.

Moving shx to devDependencies is correct as it's only used in build scripts. The update of store2 to ^2.14.3 is also good for security and bug fixes.

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]


39-57: Clarify the status of test-utils package.

The addition of test-utils export paths seems to contradict the PR objective of "deprecating packages". Please clarify if test-utils is being:

  1. Deprecated but temporarily maintained for backward compatibility
  2. Moved into the utils package instead of being deprecated
🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

packages/sdk-ts/package.json (2)

139-140: Verify crypto operations after noble packages update.

The updates to @noble/curves and addition of @noble/hashes might affect cryptographic operations. Please ensure:

  1. All crypto operations are tested with the new versions
  2. Performance impact is evaluated
  3. Security implications are reviewed
✅ Verification successful

Noble packages update appears safe

The codebase uses only stable APIs from @noble/curves (secp256k1) for basic key operations. The new @noble/hashes dependency isn't directly used in the crypto implementation. The update should be safe as:

  • Only uses stable secp256k1 methods (getPublicKey, ProjectivePoint)
  • Core crypto operations rely on crypto-js instead
  • No breaking changes detected in used functionality
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Find files using noble packages
rg "@noble/(curves|hashes)" -l

Length of output: 621


Script:

#!/bin/bash
# Check crypto.ts implementation
cat packages/sdk-ts/src/utils/crypto.ts

# Check git history for previous versions
git show HEAD:packages/sdk-ts/package.json | grep "@noble/"

Length of output: 3109

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]


11-11: Verify ESM exports configuration.

The addition of "type": "module" with the complex exports configuration needs verification. Please:

  1. Test importing the package in different environments (Node.js, bundlers)
  2. Verify all export paths resolve correctly
  3. Consider adding integration tests for package resolution
✅ Verification successful

ESM/CJS dual format configuration is correct

The package.json has a well-structured exports field with proper conditional exports for all environments (ESM, CJS, React Native) and correct type definitions. The build setup correctly handles dual-format output with separate tsconfig files and post-build steps. The missing files are expected as they are build artifacts.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if all exported paths exist
for path in $(rg '"import"|"require"' packages/sdk-ts/package.json | rg -o '"\./[^"]+\.js"' | tr -d '"'); do
  if [ ! -f "packages/sdk-ts/$path" ]; then
    echo "Missing file: $path"
  fi
done

Length of output: 2074


Script:

#!/bin/bash
# Check package.json exports and build configuration
echo "=== Package.json contents ==="
cat packages/sdk-ts/package.json

echo -e "\n=== TypeScript configs ==="
fd tsconfig.json packages/sdk-ts/

Length of output: 5987

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

Comment on lines 3 to 4
import EthereumApp from '@ledgerhq/hw-app-eth'
import Transport from '@ledgerhq/hw-transport'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Remove redundant imports of @ledgerhq/hw-app-eth.

The code has both static and dynamic imports of the same module:

  1. Static: import EthereumApp from '@ledgerhq/hw-app-eth'
  2. Dynamic: const EthereumApp = await import('@ledgerhq/hw-app-eth')

This is redundant and could cause confusion.

Choose one approach:

-import EthereumApp from '@ledgerhq/hw-app-eth'

And update the getInstance method to use the dynamic import consistently:

async getInstance(): Promise<EthereumApp> {
  if (!this.ledger) {
    const transport = await LedgerTransport.getTransport()
    const { default: EthereumApp } = await import('@ledgerhq/hw-app-eth')
    this.ledger = new EthereumApp(transport)
    // ...
  }
  return this.ledger
}

import { ChainInfo } from './types.js'

const INJ_DENOM = 'inj'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Migration of INJ_DENOM constant appears incomplete

The constant is now duplicated across the codebase:

  • Defined in packages/utils/src/constants.ts
  • Newly added in packages/networks/src/chainInfos.ts
  • Still imported from @injectivelabs/utils in multiple test files under packages/sdk-ts/

If the goal is to deprecate @injectivelabs/utils, the constant should be fully migrated to the new location and all imports should be updated accordingly.

🔗 Analysis chain

LGTM! Moving INJ_DENOM locally aligns with package deprecation goals.

The change reduces external dependencies by moving the constant locally, which is consistent with the PR's refactoring objectives.

Let's verify there are no inconsistencies in the INJ_DENOM value across the codebase:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any other declarations or usages of INJ_DENOM
# to ensure consistency across the codebase
rg -g '!*.{json,md}' "INJ_DENOM.*=.*['\"]inj['\"]" -A 1

Length of output: 293


Script:

#!/bin/bash
# Search for imports of INJ_DENOM from utils package
rg "import.*\{.*INJ_DENOM.*\}.*from.*@injectivelabs/utils" -A 1

# Also check for any other files still using the utils constant
ast-grep --pattern 'from "@injectivelabs/utils"'

Length of output: 1088

@@ -1,6 +1,6 @@
import { BigNumberInBase } from '@injectivelabs/utils'
import MsgExternalTransfer from './MsgExternalTransfer.js'
import { mockFactory } from '@injectivelabs/test-utils'
import { mockFactory } from '@injectivelabs/utils/test-utils'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Package Cleanup Required: test-utils Migration

The code migration is complete with all files using the new import path, but the old package remains as a dependency:

  • Remove @injectivelabs/test-utils from packages/sdk-ts/package.json
  • Update yarn.lock files after dependency removal
🔗 Analysis chain

LGTM! Verify test-utils package deprecation.

The import path change aligns with the package deprecation strategy.

Let's verify that the old package is being fully deprecated:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if there are any remaining references to the old package
rg -l "@injectivelabs/test-utils"

# Check if the new path is consistently used
rg -l "@injectivelabs/utils/test-utils"

Length of output: 5517


Script:

#!/bin/bash
# Check package.json content
cat packages/sdk-ts/package.json | grep -A 5 -B 5 "test-utils"

# Look for actual imports of old package
rg "from ['\"]\@injectivelabs\/test-utils['\"]"
rg "require\(['\"]\@injectivelabs\/test-utils['\"]"

Length of output: 919


Script:

#!/bin/bash
# Search for imports of the old package with fixed regex
rg "@injectivelabs/test-utils" -t ts -t js --type-add 'ts:*.{ts,tsx}' --type-add 'js:*.{js,jsx}' -g '!*.lock' -g '!package.json'

Length of output: 128

Comment on lines +13 to +15
TransactionException,
grpcErrorCodeToErrorCode,
GrpcUnaryRequestException,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Consider removing deprecated class.

The class is marked as deprecated in favor of IndexerGrpcWeb3GwApi. Consider removing this class in a future major version update to reduce maintenance overhead and prevent usage of deprecated APIs.

Comment on lines 126 to 129
return (await ethereum.request({
method: 'eth_signTypedData_v4',
params: [eip712json, address],
})
})) as Promise<string>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Fix incorrect Promise type assertion.

The type assertion as Promise<string> is incorrect as ethereum.request already returns a Promise. The result should be asserted as string.

-      })) as Promise<string>
+      })) as string
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
return (await ethereum.request({
method: 'eth_signTypedData_v4',
params: [eip712json, address],
})
})) as Promise<string>
return (await ethereum.request({
method: 'eth_signTypedData_v4',
params: [eip712json, address],
})) as string

Comment on lines 213 to 216
const receipt = (await ethereum.request({
method: 'eth_getTransactionReceipt',
params: [txHash],
})
})) as string
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Add maximum retry attempts to prevent infinite recursion.

The transactionReceiptRetry function could potentially enter an infinite recursion if the receipt is consistently unavailable. This could lead to a stack overflow.

Add a maximum retry limit:

  const interval = 1000
+ const maxRetries = 10
+ let attempts = 0
  const transactionReceiptRetry = async () => {
    const receipt = (await ethereum.request({
      method: 'eth_getTransactionReceipt',
      params: [txHash],
    })) as string

    if (!receipt) {
+     if (attempts >= maxRetries) {
+       throw new Error('Maximum retry attempts reached')
+     }
+     attempts++
      await sleep(interval)
      await transactionReceiptRetry()
    }

    return receipt
  }

Committable suggestion skipped: line range outside the PR's diff.

@@ -278,7 +278,7 @@ export default class WalletConnect
}

async onAccountChange(
callback: (account: AccountAddress) => void,
callback: (account: AccountAddress | string[]) => void,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Resolve type inconsistency in callback usage.

While the callback type suggests it can receive either AccountAddress | string[], the implementation always passes a single account (accounts[0]). This could lead to confusion for consumers expecting to receive the full array.

Consider either:

  1. Updating the implementation to pass the full array:
-wc.on('accountsChanged', (accounts) => callback(accounts[0]))
+wc.on('accountsChanged', (accounts) => callback(accounts))
  1. Or keeping the type specific to what's actually passed:
-callback: (account: AccountAddress | string[]) => void,
+callback: (account: AccountAddress) => void,

Committable suggestion skipped: line range outside the PR's diff.

Comment on lines +74 to +75
"@types/jest": "^29.5.14",
"@types/node": "^22.10.1",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Address peer dependency warnings.

The pipeline shows warnings about missing peer dependencies:

  1. @babel/core is missing
  2. typedoc-monorepo-link-types requires [email protected]

Consider:

  1. Adding @babel/core as a dev dependency
  2. Updating typedoc to match the required version or updating typedoc-monorepo-link-types

Also applies to: 93-96, 100-100, 112-112

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

@@ -14,7 +14,7 @@
},
"scripts": {
"postinstall": "node etc/bootstrapEnv",
"build": "node etc/bootstrapEnv && lerna run build",
"build": "node etc/bootstrapEnv && patch-package && lerna run build",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Document the purpose and status of 8 wallet-related patches

Found 8 undocumented patches for wallet connectivity dependencies:

  • 5 Ledger hardware wallet patches (@ledgerhq/*)
  • 1 Trezor connection patch (@trezor/connect-web)
  • 1 WalletConnect provider patch
  • 1 store2 utility patch

Please document:

  1. The purpose of each patch and why it's needed
  2. Whether these are temporary workarounds or permanent solutions
  3. If there are related upstream issues that need to be tracked
🔗 Analysis chain

Document patch-package usage.

The addition of patch-package to build and bootstrap scripts indicates custom patches are being applied. Please:

  1. Document the patches in the PR description
  2. Add a README section explaining which packages are patched and why
  3. Consider if these patches are temporary or need upstream fixes

Also applies to: 38-38

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for existing patches
fd -t f . patches/

Length of output: 375


Script:

#!/bin/bash
# Check README files and documentation
echo "=== Searching for patch documentation in README files ==="
fd -t f -e md . | xargs rg -i "patch" -C2

echo -e "\n=== Checking PR description if available ==="
gh pr view --json body | jq -r .body

Length of output: 361

🧰 Tools
🪛 GitHub Actions: Publish canary branch

[warning] Missing peer dependency '@babel/core' for multiple packages


[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]

@ThomasRalee ThomasRalee force-pushed the refactor/canary-esm-build-and-deprecating-packages branch from 0ccb2da to 43cd4c0 Compare February 3, 2025 13:23
@ThomasRalee ThomasRalee force-pushed the refactor/canary-esm-build-and-deprecating-packages branch from 43cd4c0 to c17bf9f Compare February 3, 2025 14:19
Copy link

socket-security bot commented Feb 3, 2025

Report too large to display inline

View full report↗︎

ThomasRalee and others added 3 commits February 3, 2025 14:22
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
 - @injectivelabs/[email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants