refactor/esm build and deprecating packages #526
Conversation
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
packages/utils/src/classes/LocalStorage.tsOops! Something went wrong! :( ESLint: 7.32.0 Error: Error while loading rule 'jest/unbound-method': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the "parserOptions.project" property for @typescript-eslint/parser. WalkthroughThe pull request introduces multiple changes across various modules, focusing primarily on enhancing type safety and error handling in asynchronous methods. Key modifications include updating method signatures to accommodate new types, particularly allowing callbacks to handle multiple account addresses. Additionally, several methods have been refactored to utilize a new error handling utility, Changes
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat 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. What is a typosquat?Package name is similar to other popular packages and may not be the package you want. Use care when consuming similarly named packages and ensure that you did not intend to consume a different package. Malicious packages often publish using similar names as existing popular packages. Take a deeper look at the dependencyTake 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 packageIf 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 riskTo ignore an alert, reply with a comment starting with
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
🧹 Outside diff range and nitpick comments (40)
packages/exceptions/tsconfig.build.esm.json (1)
4-4: LGTM! Appropriate module configuration for Node.js ESM supportThe changes to
moduleandmoduleResolutionalign well with modern Node.js ESM practices. UsingNodeNextprovides better compatibility and clearer module resolution rules compared to the previous configuration.These changes will:
- Enable proper ESM/CommonJS interoperability
- Support package.json exports
- Provide consistent resolution behavior across different Node.js versions
Also applies to: 10-10
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts (2)
241-244: Consider stronger typing for transaction receiptWhile the type assertion to
stringworks, consider using a more specific type that matches the Ethereum transaction receipt structure for better type safety and autocomplete support.- })) as string + })) as { + transactionHash: string; + transactionIndex: string; + blockHash: string; + blockNumber: string; + status: string; + // ... other receipt fields + }
Line range hint
1-324: Note: This file is in a deprecated packageSince this file is in a
deprecatedfolder, consider:
- Documenting the migration path for users
- Adding a deprecation notice with the intended removal timeline
- Referencing the replacement implementation if available
🧰 Tools
🪛 Biome (1.9.4)
[error] 30-32: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
packages/sdk-ts/src/utils/crypto.ts (1)
83-84: Redundant buffer conversion indecompressPubKeyfunctionThe code unnecessarily wraps
testBufferwithBuffer.frombefore converting it to a hex string. SincetestBufferis already a Buffer, you can directly convert it to a hex string.Apply this diff to simplify the code:
const point = secp256k1.ProjectivePoint.fromHex( - Buffer.from(testBuffer).toString('hex'), + testBuffer.toString('hex'), )packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts (1)
1-3: Consider documenting ESM transition strategyThe codebase shows mixed approaches to ESM transition:
- Some configs fully embrace ESM (jest.config.js)
- Some tests use deprecated CJS paths
- Others use new ESM-compatible paths
To ensure a smooth transition, consider:
- Documenting the preferred import pattern for test utilities
- Creating a migration guide for transitioning remaining CJS usage
- Adding ESM compatibility checks to CI
Would you like help creating a migration guide or CI checks for ESM compatibility?
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (2)
Line range hint
31-57: Remove commented-out test code.Instead of keeping commented-out test code, it should be removed. If the test is temporarily disabled, consider using
test.skip()with a TODO comment explaining why it's skipped.-// test('fetchAccountPortfolioTokenHolders', async () => { -// try { -// const response = -// await indexerGrpcPortfolioApi.fetchAccountPortfolioTokenHolders({ -// denom: INJ_DENOM, -// }) - -// expect(response).toBeDefined() -// expect(response).toEqual( -// expect.objectContaining< -// ReturnType< -// typeof IndexerGrpcAccountPortfolioTransformer.tokenHoldersResponseToTokenHolders -// > -// >(response), -// ) -// } catch (e) { -// console.error( -// 'IndexerGrpcAccountPortfolioApi.fetchAccountPortfolioTokenHolders => ' + -// (e as any).message, -// ) -// } -// }) +test.skip('fetchAccountPortfolioTokenHolders', async () => { + // TODO: Re-enable this test once the functionality is ready +})
Line range hint
15-30: Improve error handling in tests.The current error handling approach has several issues:
- Using console.error in tests isn't ideal as it makes test output noisy
- The test will pass even if an error occurs
- No assertions for expected error cases
Consider refactoring to properly handle and assert errors:
test('fetchAccountPortfolio', async () => { - 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, - ) - } + const response = await indexerGrpcPortfolioApi.fetchAccountPortfolio( + injectiveAddress, + ) + + expect(response).toBeDefined() + expect(response).toEqual( + expect.objectContaining< + ReturnType< + typeof IndexerGrpcAccountPortfolioTransformer.accountPortfolioResponseToAccountPortfolio + > + >(response), + ) }) + +test('fetchAccountPortfolio handles errors', async () => { + const invalidAddress = 'invalid-address' + + await expect( + indexerGrpcPortfolioApi.fetchAccountPortfolio(invalidAddress) + ).rejects.toThrow() +})packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgBurn.spec.ts (1)
1-3: Consider documenting the utils package organizationThe refactoring of utils and test-utils looks good. Consider adding a README.md in the utils package to document the new organization and migration path for other developers.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts (1)
Line range hint
41-43: Fix incorrect error messages in catch blocks.The error messages reference wrong method names:
- 'fetchModuleState' should be 'fetchAccount'
- 'fetchCurrentBasket' should be 'fetchAccounts'
Apply this diff to fix the error messages:
- 'ChainGrpcAuthApi.fetchModuleState => ' + (e as any).message, + 'ChainGrpcAuthApi.fetchAccount => ' + (e as any).message, - 'ChainGrpcAuthApi.fetchCurrentBasket => ' + (e as any).message, + 'ChainGrpcAuthApi.fetchAccounts => ' + (e as any).message,Also applies to: 56-58
packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (1)
2-3: Consider documenting the package restructuringThe systematic reorganization of test utilities from
@injectivelabs/test-utilsto@injectivelabs/utils/test-utilsappears to be part of a larger ESM compatibility effort. Consider:
- Documenting these changes in the migration guide
- Updating the package README to reflect the new structure
- Adding deprecation notices for the old package path
This will help downstream consumers adapt to the new package structure.
packages/sdk-ts/src/core/modules/auction/msgs/MsgBid.spec.ts (1)
2-2: LGTM! Import path updated consistently.The change aligns with the ESM migration and package reorganization.
Consider updating the package's README or migration guide to document the deprecation of
@injectivelabs/test-utilsand the new import path for test utilities.packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts (1)
1-3: Architectural Changes Look GoodThe systematic updates across test files demonstrate a well-structured approach to:
- ESM module compatibility (using .js extensions)
- Package organization (consolidating test utilities)
- Deprecating standalone packages in favor of a more modular structure
This should improve maintainability and reduce package overhead.
packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts (1)
1-3: Consider documenting the test utilities migrationGiven the widespread changes to test utility imports across the codebase, consider:
- Adding a migration guide in the documentation
- Including the rationale for the reorganization
- Documenting any breaking changes for downstream consumers
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)
63-63: Address TODO comment in fetchModuleState methodThe TODO comment suggests potential incomplete implementation or missing functionality.
Would you like me to help implement the missing functionality or create a GitHub issue to track this task?
packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts (1)
Line range hint
27-27: Address the TODO comment and enable the skipped tests.The test suite is currently skipped with a TODO comment. Please review and enable these tests to ensure proper coverage of the
MsgInstantSpotMarketLaunchfunctionality.Would you like me to help investigate why these tests were skipped and propose a solution?
packages/sdk-ts/src/utils/address.ts (1)
107-111: Add input validation for hex string utilitiesWhile the implementation is correct, consider adding input validation to ensure the input is a valid hex string.
Consider this enhanced implementation:
-export const addHexPrefix = (hex: string) => - hex.startsWith('0x') ? hex : `0x${hex}` +export const addHexPrefix = (hex: string) => { + if (typeof hex !== 'string') { + throw new Error('Input must be a string') + } + if (!/^(0x)?[0-9a-fA-F]+$/.test(hex)) { + throw new Error('Invalid hex string') + } + return hex.startsWith('0x') ? hex : `0x${hex}` +} -export const removeHexPrefix = (hex: string) => - hex.startsWith('0x') ? hex.slice(2) : hex +export const removeHexPrefix = (hex: string) => { + if (typeof hex !== 'string') { + throw new Error('Input must be a string') + } + if (!/^(0x)?[0-9a-fA-F]+$/.test(hex)) { + throw new Error('Invalid hex string') + } + return hex.startsWith('0x') ? hex.slice(2) : hex +}packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (1)
95-98: Update error context for consistencyThe error context in
fetchAccountPortfolioBalancesshould be 'AccountPortfolioBalances' instead of 'AccountPortfolio' for better error tracking.throw new GrpcUnaryRequestException(new Error(e.toString()), { code: grpcErrorCodeToErrorCode(e.code), - context: 'AccountPortfolio', + context: 'AccountPortfolioBalances', contextModule: this.module, })packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts (1)
Line range hint
14-98: Improve test error handlingThe current error handling using try-catch with console.error could be improved. Consider using proper test failure mechanisms instead of silently logging errors.
Consider this pattern instead:
test('fetchModuleParams', async () => { - try { - const response = await chainGrpcBankApi.fetchModuleParams() - expect(response).toBeDefined() - expect(response).toEqual( - expect.objectContaining< - ReturnType< - typeof ChainGrpcBankTransformer.moduleParamsResponseToModuleParams - > - >(response), - ) - } catch (e) { - console.error( - 'ChainGrpcBankApi.fetchModuleParams => ' + (e as any).message, - ) - } + const response = await chainGrpcBankApi.fetchModuleParams() + expect(response).toBeDefined() + expect(response).toEqual( + expect.objectContaining< + ReturnType< + typeof ChainGrpcBankTransformer.moduleParamsResponseToModuleParams + > + >(response), + ) })This allows test failures to be properly reported rather than silently logged. If you need to test error cases, use
expect().rejects.toThrow()instead.packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts (1)
3-4: Consider extracting common error handling logicThe addition of
grpcErrorCodeToErrorCodeimproves error handling consistency, but the error handling pattern is repeated across multiple methods.Consider extracting the common error handling pattern into a utility method:
+ private handleGrpcError(e: unknown, context: string) { + if (e instanceof InjectiveAuctionV1Beta1Query.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, + }) + }This would reduce code duplication and make the error handling more maintainable.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts (1)
Line range hint
24-33: Consider improving test error handling.The current error handling pattern in tests simply logs errors without failing the test. This could mask potential issues. Consider either:
- Removing the try-catch and letting the test fail naturally, or
- Adding explicit test failure using
expect.fail()in the catch blockExample refactor for one test case:
test('fetchCampaign', async () => { - try { const response = await indexerGrpcCampaignApi.fetchCampaign({ marketId: MARKET_ID, campaignId: CAMPAIGN_ID, }) expect(response).toBeDefined() expect(response).toEqual( expect.objectContaining< ReturnType< typeof IndexerCampaignTransformer.CampaignResponseToCampaign > >(response), ) - } catch (e) { - console.error( - 'IndexerGrpcCampaignApi.fetchCampaign => ' + (e as any).message, - ) - } })Also applies to: 51-60, 76-85, 101-110, 126-135
packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts (1)
Line range hint
3-7: Clean up commented-out code.There are several commented-out imports and a test case that should either be:
- Removed if they're no longer needed
- Uncommented if they're still required
- Converted to a TODO comment if they represent future work
If this is intended for future work, consider replacing with:
- // import { Network, getNetworkEndpoints } from '@injectivelabs/networks' - // import { getEthereumAddress } from '../../../../utils/address' - // import { IndexerGrpcTransactionApi } from '../../../../client' - // import { DEFAULT_GAS_LIMIT } from '@injectivelabs/utils' - // import { EthereumChainId } from '@injectivelabs/ts-types' + // TODO: Implement EIP712 chain comparison testAlso applies to: 142-167
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.ts (1)
3-4: Consider extracting common error handling logicThe error handling pattern is repeated across multiple methods with the same structure, only differing in context. Consider extracting this to a common utility method to reduce code duplication.
+ private handleGrpcError(e: unknown, context: string) { + if (e instanceof CosmosAuthV1Beta1Query.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, + }) + } async fetchModuleParams() { try { // ... existing try block ... } catch (e: unknown) { - if (e instanceof CosmosAuthV1Beta1Query.GrpcWebError) { - throw new GrpcUnaryRequestException(new Error(e.toString()), { - code: grpcErrorCodeToErrorCode(e.code), - context: 'Params', - contextModule: this.module, - }) - } - - throw new GrpcUnaryRequestException(e as Error, { - code: UnspecifiedErrorCode, - context: 'Params', - contextModule: this.module, - }) + this.handleGrpcError(e, 'Params') } }Also applies to: 44-44, 73-73, 105-105
packages/sdk-ts/src/client/chain/grpc/ChainGrpcMintApi.ts (1)
3-4: Apply consistent error handling patternSimilar to ChainGrpcAuthApi, consider extracting the repeated error handling pattern into a utility method.
+ private handleGrpcError(e: unknown, context: string) { + if (e instanceof CosmosMintV1Beta1Query.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, + }) + }Also applies to: 45-45, 76-76, 107-107
packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.spec.ts (2)
Line range hint
7-9: Consider using mock endpoints for testingUsing live MainnetSentry endpoints in tests could make them unreliable and dependent on network conditions.
Consider:
- Using mock endpoints for testing
- Adding retry logic for network failures
- Implementing proper test doubles
-const endpoints = getNetworkEndpoints(Network.MainnetSentry) +const endpoints = { + grpc: 'mock-grpc-endpoint', + indexer: 'mock-indexer-endpoint' +}
Line range hint
13-122: Improve error handling and test reliabilityThe current error handling simply logs errors, which could mask test failures.
Consider these improvements:
- Use proper test assertions for errors
- Add timeout handling
- Implement proper cleanup after each test
test('fetchModuleParams', async () => { - try { - const response = await chainGrpcIbcApi.fetchModuleParams() + const response = await chainGrpcIbcApi.fetchModuleParams() - expect(response).toBeDefined() - expect(response).toEqual( - expect.objectContaining< - ReturnType< - typeof ChainGrpcInsuranceFundTransformer.moduleParamsResponseToModuleParams - > - >(response), - ) - } catch (e) { - console.error( - 'chainGrpcIbcApi.fetchModuleParams => ' + (e as any).message, - ) - } + expect(response).toBeDefined() + expect(response).toEqual( + expect.objectContaining< + ReturnType< + typeof ChainGrpcInsuranceFundTransformer.moduleParamsResponseToModuleParams + > + >(response), + ) })packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts (1)
39-39: Consider enhancing error type safetyWhile the error handling improvements are good, consider adding a type guard or custom error type for the 'object not found' check in fetchOraclePriceNoThrow to avoid using
as any.- if ((e as any).message.includes('object not found')) { + if (e instanceof Error && e.message.includes('object not found')) {Also applies to: 83-83, 133-133
packages/sdk-ts/src/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts (1)
Based on the implementation file and related test files, I can now generate a final response:
Implement test suite following established authz message test patterns
The skipped test suite for
MsgGrantWithAuthorizationshould be implemented following the same pattern as other authz message tests in the codebase. The implementation should verify:
- Proto message generation
- Data structure conversion
- Amino encoding
- EIP712 types and values
- Web3 format conversion
Similar test files (
MsgGrant.spec.ts,MsgRevoke.spec.ts, andMsgExec.spec.ts) provide clear examples of the testing structure and assertions needed.🔗 Analysis chain
Line range hint
11-11: Address skipped test suiteThe test suite is marked with TODO and skipped. Consider either implementing the missing tests or documenting the reason for skipping.
Let's check if there are other skipped tests in the codebase:
Would you like help implementing the missing tests or documenting the reason for skipping?
Let me analyze the results. I can see that there are several skipped tests in the codebase, and specifically for the file in question (
MsgGrantWithAuthorization.spec.ts), there's a TODO comment followed by a skipped test suite. Let me check if there's any implementation or related files that might give us context about why this test is skipped.
Let me check if there are any existing tests for similar authorization-related messages to understand the testing pattern.
Let me try a different approach to find any related test files.
Let me check the content of these related test files to see if they have implemented tests that could serve as a reference for implementing the skipped tests.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for skipped tests and TODO comments in test files rg -g "*.spec.ts" -g "*.test.ts" "describe\.skip|test\.skip|TODO" --context 2Length of output: 7335
Script:
#!/bin/bash # Check for the implementation file and any related files fd MsgGrantWithAuthorization.ts --exec cat {}Length of output: 3803
Script:
#!/bin/bash # Look for other authz-related test files rg -g "*.spec.ts" "describe\(.*authz" -A 5Length of output: 44
Script:
#!/bin/bash # Look for other authz-related test files with a broader search fd -e spec.ts -e test.ts . | grep -i authzLength of output: 305
Script:
#!/bin/bash # Check contents of the related authz test files cat packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.tsLength of output: 6575
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)
Line range hint
16-24: Consider enhancing test error handling.The current error handling pattern across all tests simply logs errors to console. Consider:
- Using proper test assertions for expected errors
- Failing tests explicitly when unexpected errors occur
Example improvement pattern:
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, - ) + // Handle expected errors + if (e instanceof ExpectedError) { + expect(e.message).toMatch(/expected error pattern/) + return + } + // Fail test for unexpected errors + throw e } })Also applies to: 37-45, 54-62, 71-79, 88-96, 105-113, 122-130, 139-147, 156-164
packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts (1)
46-46: LGTM! Consistent error code handling implementation.The standardized use of
grpcErrorCodeToErrorCodeacross all methods improves error handling consistency and maintainability.This change is part of a broader effort to standardize error handling across the codebase, which will make error handling more predictable and easier to maintain.
Also applies to: 83-83, 111-111, 138-138, 175-175, 205-205
packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts (1)
43-43: LGTM! Comprehensive error handling implementation.The standardized use of
grpcErrorCodeToErrorCodeis properly implemented across all methods, including NoThrow variants, while maintaining contextModule information.The consistent error handling approach across different method variants (standard and NoThrow) improves code predictability and maintainability.
Also applies to: 82-82, 128-128, 160-160, 196-196
packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts (1)
52-52: Improved error handling consistency across all methods.The error handling has been standardized to use grpcErrorCodeToErrorCode for all gRPC errors, providing consistent error codes throughout the API.
Consider creating a base error handling method to reduce code duplication across these similar catch blocks.
+ private handleGrpcError(e: any, context: string) { + if (e instanceof CosmosGovV1Query.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, + }) + }Also applies to: 93-93, 121-121, 161-161, 200-200, 228-228
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (2)
Line range hint
245-257: Fix incorrect event listener nameThe event listener is using 'leap_keystorechange' instead of 'ninji_keystorechange', which is incorrect for the Ninji wallet implementation.
- window.addEventListener('leap_keystorechange', listener) + window.addEventListener('ninji_keystorechange', listener)
Line range hint
245-250: Consider utilizing the full callback type capabilityWhile the callback type now supports both single address and array of addresses, the implementation only passes a single address. Consider passing the full array of addresses to give consumers more flexibility.
- callback(account) + const addresses = await this.getAddresses() + callback(addresses)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/TrustWallet/index.ts (1)
42-44: Improve type safety in ethereum request handlingThe type assertion
as string[]is correct but could be more specific. Consider using a type guard or runtime validation to ensure the response matches the expected format.- })) as string[] + })).map((account): string => { + if (typeof account !== 'string') { + throw new Error('Invalid account format received') + } + return account + })deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts (1)
70-70: Consider using a type guard instead of type assertionsThe code uses multiple type assertions (
as string[]andas string) for Ethereum request responses. While this works, it might mask potential type-related issues at runtime. Consider implementing a type guard function to validate the response type before asserting.function isStringArray(value: unknown): value is string[] { return Array.isArray(value) && value.every(item => typeof item === 'string'); } function isString(value: unknown): value is string { return typeof value === 'string'; }Also applies to: 99-99, 155-155, 210-210, 224-224, 242-242
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts (1)
4-4: Consider documenting the error code mappingThe
grpcErrorCodeToErrorCodefunction is used across multiple catch blocks, but its mapping logic isn't immediately clear to developers.Consider adding a comment or documentation that explains the error code transformation logic.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)
39-39: Consider extracting the error handling logicThe error handling pattern is repeated across all methods. Consider extracting this into a utility function to reduce code duplication and improve maintainability.
Example implementation:
private handleGrpcError(e: unknown, context: string) { if (e instanceof InjectiveExplorerRpc.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, }) }Also applies to: 70-70, 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/chain/grpc/ChainGrpcStakingApi.ts (1)
44-44: Consider a more sophisticated error handling utilityThe error handling pattern is repeated across methods, including NoThrow variants. Consider creating a more sophisticated utility that can handle both standard and NoThrow cases.
Example implementation:
private handleGrpcError(e: unknown, context: string, options?: { noThrow?: boolean, notFoundReturn?: any }) { if (options?.noThrow && (e as any).message.includes('does not exist')) { return options.notFoundReturn; } if (e instanceof CosmosStakingV1Beta1Query.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, }) }Also applies to: 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)
23-27: Consider adding validation in the error code conversionThe current implementation assumes the input will always be a valid gRPC error code. Consider adding validation to handle unexpected values.
export const grpcErrorCodeToErrorCode = <T extends number>( grpcErrorCode: T, ): GrpcErrorCode => { - return grpcErrorCode as GrpcErrorCode + if (grpcErrorCode >= 0 && grpcErrorCode <= 16) { + return grpcErrorCode as GrpcErrorCode + } + return GrpcErrorCode.Unknown }packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts (1)
101-103: Remove extra newline in error object propertiesThere's an unnecessary empty line between
contextandcontextModuleproperties that should be removed for consistency with other error objects in the file.{ code: grpcErrorCodeToErrorCode(e.code), context: 'FeeDiscountSchedule', - contextModule: this.module, }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 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(2 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(2 hunks)packages/networks/src/chainInfos.ts(1 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(3 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(11 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(3 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(1 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)packages/wallet-ts/LICENSE(0 hunks)packages/wallet-ts/jest.config.js(0 hunks)
⛔ Files not processed due to max files limit (57)
- 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
- packages/wallets/wallet-trezor/tsconfig.build.esm.json
- packages/wallets/wallet-trezor/tsconfig.build.json
💤 Files with no reviewable changes (12)
- packages/test-utils/tsconfig.json
- lerna.json
- packages/test-utils/README.md
- packages/wallet-ts/jest.config.js
- packages/wallet-ts/.npmignore
- packages/test-utils/tsconfig.build.json
- packages/test-utils/tsconfig.build.esm.json
- packages/test-utils/package.json
- etc/replacements.js
- packages/test-utils/CHANGELOG.md
- etc/replacements-ledger.js
- packages/wallet-ts/LICENSE
✅ Files skipped from review due to trivial changes (13)
- deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/Base.ts
- packages/ts-types/tsconfig.build.json
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateParams.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.spec.ts
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespace.spec.ts
- packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgSetDenomMetadata.spec.ts
- packages/networks/src/chainInfos.ts
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgCreateNamespace.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.spec.ts
- packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.ts
- packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts
- packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgChangeAdmin.spec.ts
- packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.spec.ts
🔇 Additional comments (146)
packages/sdk-ts/src/client/chain/grpc/ChainGrpcTendermintApi.ts (2)
6-7: LGTM! Import changes align with error handling standardization
The addition of grpcErrorCodeToErrorCode import supports the standardized error handling approach being implemented across the codebase.
39-39: LGTM! Enhanced error handling with standardized error code mapping
The change improves error handling consistency by using grpcErrorCodeToErrorCode for standardized error code mapping.
Let's verify consistent error handling implementation across similar files:
✅ Verification successful
Standardized error handling verified across all GRPC API files
The verification results show that all GRPC API files consistently use the grpcErrorCodeToErrorCode function for error handling. Every file that throws GrpcUnaryRequestException properly maps the error codes using this standardized function, confirming uniform error handling implementation across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if other GRPC API files follow the same error handling pattern
# Expected: All GRPC API files should use grpcErrorCodeToErrorCode for error handling
# Search for similar GRPC API files and their error handling
rg -l "GrpcUnaryRequestException" | grep "grpc" | while read -r file; do
echo "=== Checking $file ==="
rg "grpcErrorCodeToErrorCode" "$file" || echo "Missing standardized error handling"
done
Length of output: 20364
packages/sdk-ts/src/client/chain/grpc/ChainGrpcOracleApi.ts (2)
3-4: LGTM! Import changes align with standardized error handling.
The addition of grpcErrorCodeToErrorCode utility and reorganization of imports support the broader effort to standardize error handling across the codebase.
39-39: LGTM! Enhanced error handling with standardized error codes.
The update to use grpcErrorCodeToErrorCode improves consistency in error handling across the SDK.
Let's verify this pattern is consistently applied across other gRPC API clients:
✅ Verification successful
The previous ast-grep pattern might have been too specific. Let's search more broadly for the error handling pattern and files that might contain it.
LGTM! The error handling pattern using grpcErrorCodeToErrorCode is consistently applied across the codebase.
The search results confirm that the error handling pattern using grpcErrorCodeToErrorCode is consistently implemented across all gRPC API clients in the codebase, including:
- Chain gRPC APIs (Oracle, etc.)
- Indexer gRPC APIs (Derivatives, Spot, Explorer, etc.)
- Transaction gRPC APIs
- Core gRPC APIs
The standardized error handling ensures consistent error code transformation and proper error context across all gRPC interactions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent error handling pattern across gRPC API clients
# Expected: All gRPC API clients should use grpcErrorCodeToErrorCode for error handling
# Search for similar error handling patterns in other gRPC API clients
ast-grep --pattern 'catch (e: unknown) {
if (e instanceof $$$GrpcWebError) {
throw new GrpcUnaryRequestException($$$, {
code: grpcErrorCodeToErrorCode(e.code),
$$$
})
}
}'
Length of output: 197
Script:
#!/bin/bash
# Let's try a different approach to search for error handling patterns
# First, let's find all files that might contain gRPC API clients
fd "GrpcApi" packages/sdk-ts/src
# Then search for error handling patterns using ripgrep
rg "grpcErrorCodeToErrorCode" packages/sdk-ts/src -B 2 -A 2
Length of output: 65629
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts (1)
Line range hint 1-89: Add proper deprecation notices and migration documentation
This file is in a deprecated directory but lacks proper deprecation notices. Given that this is critical infrastructure code handling hardware wallet interactions, it's important to:
- Add JSDoc deprecation notices with migration guidance
- Document the replacement implementation path
- Consider adding runtime deprecation warnings
Add the following at the class level:
+/**
+ * @deprecated This implementation is deprecated and will be removed in the next major version.
+ * Please use the new implementation from '@injectivelabs/wallet-ts/next' instead.
+ * Migration guide: [Add link to migration guide]
+ */
export default class LedgerTransport {Let's verify if there's a replacement implementation:
✅ Verification successful
Based on the search results, I can now generate the final response:
Add proper deprecation notice and point to @injectivelabs/wallet-strategy
The file is in a deprecated package that has a clear migration path to @injectivelabs/wallet-strategy. Let's update the deprecation notice to be more specific:
+/**
+ * @deprecated This implementation has been moved to @injectivelabs/wallet-strategy.
+ * Please use LedgerStrategy from @injectivelabs/wallet-strategy instead.
+ * See README.md in @injectivelabs/wallet-ts for migration instructions.
+ */
export default class LedgerTransport {The search results show:
- The entire
@injectivelabs/wallet-tspackage is deprecated in favor of@injectivelabs/wallet-strategy - The new implementation exists in
packages/wallets/wallet-ledger/ - Migration documentation is available in the wallet-ts README
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potential new implementations of Ledger transport
fd -e ts -e js "Ledger.*Transport" | grep -v "deprecated"
Length of output: 57
Script:
#!/bin/bash
# Let's try a broader search for Ledger-related files and potential new implementations
fd -t f -e ts -e js "ledger" --ignore-case
# Also search for potential migration guides or documentation
fd -t f "MIGRATION" --ignore-case
fd -t f "README" --ignore-case
Length of output: 1337
Script:
#!/bin/bash
# Search for any references to new wallet implementations
rg -i "new.*wallet" -g "*.{ts,js,md}"
Length of output: 65576
Script:
#!/bin/bash
# Look for any deprecation notices or migration paths in package.json files
fd "package.json" --exec cat {} | jq -r '. | select(.deprecated != null) | .name + ": " + .deprecated'
Length of output: 104
Script:
#!/bin/bash
# Search for any documentation about wallet migration
rg -i "migration|deprecat" -g "*.md"
Length of output: 294
packages/utils/src/helpers.ts (2)
80-82: LGTM: Improved precision with BigNumberInBase
The switch to BigNumberInBase for gas normalization is a good improvement for numerical precision.
115-116: Verify gas calculation changes across the codebase
The changes to use BigNumberInBase for gas calculations look good, but we should verify that all consumers of these functions are prepared for the potentially different precision in the results.
Also applies to: 122-124, 127-127
✅ Verification successful
Based on the comprehensive output, I can now generate the final response:
The gas calculation changes are safe and consistent across the codebase
The switch to BigNumberInBase for gas calculations in helpers.ts is safe because:
- All gas calculations throughout the codebase already use BigNumber-based calculations
- The broadcasters (
MsgBroadcasterandMsgBroadcasterWithPk) properly handle gas calculations using BigNumber - Gas buffer coefficients (1.1 or 1.2) are applied consistently using BigNumber operations
- All consumers of these functions already expect and handle BigNumber precision
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for direct usage of these gas calculation functions
echo "Searching for getStdFeeFromObject usage..."
rg "getStdFeeFromObject" -A 3
echo "Searching for getStdFeeForToken usage..."
rg "getStdFeeForToken" -A 3
# Search for any gas-related calculations that might need similar precision improvements
echo "Searching for other gas calculations..."
rg "gas.*BigNumber(?!InBase)" --type typescript
Length of output: 1381
Script:
#!/bin/bash
# Let's try a different approach to find gas calculations and BigNumber usage
# Search for files that use BigNumber and contain gas-related calculations
echo "Files using BigNumber and containing gas calculations:"
rg -l "BigNumber" | xargs rg -l "gas"
# Look for gas price calculations
echo -e "\nGas price calculations:"
rg "gasPrice" -A 2 --type typescript
# Look for gas amount calculations
echo -e "\nGas amount calculations:"
rg "\.gas\b|gas:" -A 2 --type typescript
# Look specifically for BigNumber instantiations with gas
echo -e "\nBigNumber instantiations with gas:"
rg "new BigNumber.*gas" --type typescript
Length of output: 2472
Script:
#!/bin/bash
# Let's focus on the specific files we found and examine their gas calculations
echo "Checking gas calculations in SDK and Utils packages:"
# Check utils/helpers.ts for all gas-related calculations
echo "=== Gas calculations in utils/helpers.ts ==="
rg "gas" -A 3 packages/utils/src/helpers.ts
# Check tx-related files for gas calculations
echo -e "\n=== Gas calculations in tx-related files ==="
rg "gas" -A 3 packages/sdk-ts/src/core/tx/tx.ts
rg "gas" -A 3 packages/sdk-ts/src/core/tx/api/TxRestApi.ts
rg "gas" -A 3 packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts
# Check broadcaster implementations
echo -e "\n=== Gas calculations in broadcasters ==="
rg "gas" -A 3 packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.ts
rg "gas" -A 3 packages/wallets/wallet-core/src/broadcaster/MsgBroadcaster.ts
# Look for BigNumber usage in these specific files
echo -e "\n=== BigNumber usage in relevant files ==="
rg "BigNumber" -A 3 packages/utils/src/helpers.ts
rg "BigNumber" -A 3 packages/sdk-ts/src/core/tx/tx.ts
Length of output: 10564
packages/utils/tsconfig.build.esm.json (1)
4-4: Approve TypeScript module configuration changes
The switch to "NodeNext" for both module and moduleResolution aligns with modern Node.js ESM practices and provides better type safety for ESM imports/exports.
Let's verify the impact on import statements in the codebase:
Also applies to: 10-10
✅ Verification successful
All imports are properly configured for NodeNext module resolution
The verification shows that:
- All internal imports correctly use the
.jsextension as required by NodeNext - External package imports are correctly written without extensions
- No package.json files without "type": "module" were found, indicating proper ESM configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential issues with import statements that might need updates
# Look for .js extensions in imports which are now required with NodeNext
rg -g '*.ts' -g '!*.d.ts' "from ['\"].*[^.]['\"]" ./packages/utils/src/
# Check for any package.json type field which should be "module" for ESM
find ./packages/utils -name "package.json" -exec cat {} \; | jq 'select(.type != "module")'
Length of output: 4265
packages/sdk-ts/tsconfig.build.esm.json (1)
4-4: Verify SDK package compatibility with NodeNext resolution
The module configuration changes are consistent with other packages, which is good. However, as this is the SDK package, we should ensure all consumers can handle these changes.
Let's check for potential compatibility issues:
Also applies to: 10-10
✅ Verification successful
Based on the extensive codebase analysis showing the exports and module structure, I can now generate the final response:
NodeNext module resolution is safe to use in the SDK package
The SDK package is well-structured with proper ES modules usage throughout:
- All exports use
.jsextensions in import/export paths - Modules are properly organized with index.js files
- No CommonJS-specific syntax or patterns are used
The change to "NodeNext" resolution is compatible with both Node.js and bundler environments that support ES modules.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any external-facing API exports that might be affected
rg -g '*.ts' "export \*|export \{" ./packages/sdk-ts/src/
# Look for any barrel files (index.ts) that might need updates
find ./packages/sdk-ts/src -name "index.ts" -exec cat {} \;
Length of output: 64662
packages/ts-types/tsconfig.build.esm.json (1)
4-4: Ensure type definitions remain compatible with consumers
The module configuration changes are appropriate, but as this package provides types, we should ensure type exports remain accessible to all consumers.
Consider documenting in the README that consumers might need to update their TypeScript configuration to handle these types correctly when using the ESM build.
Let's verify the type export patterns:
Also applies to: 10-10
✅ Verification successful
Type exports are properly configured for both CJS and ESM consumption
The package.json correctly defines dual package exports with proper type declarations for both CJS and ESM formats. The extensive usage across multiple packages in the monorepo (wallets, sdk-ts, networks, etc.) is already supported through the conditional exports configuration. No compatibility issues are expected as:
- Type definitions are properly mapped for both formats:
- CJS:
dist/cjs/index.d.ts - ESM:
dist/esm/index.d.ts
- CJS:
- The exports field handles all consumption scenarios including react-native
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check type export patterns that might need updates
rg -g '*.ts' "export type|export interface" ./packages/ts-types/src/
# Look for any type-only imports that might be affected
rg -g '*.ts' "import type" ./packages/ts-types/src/
Length of output: 727
Script:
#!/bin/bash
# Let's check if there are any consumers of these types within the monorepo
rg -g '*.ts' -l "from ['\"]@injectivelabs/ts-types['\"]" ./packages/
# Check the package.json to understand the package's exports configuration
cat ./packages/ts-types/package.json
# Check if there's any documentation about module/type usage
fd "README.md" ./packages/ts-types/
Length of output: 7351
packages/networks/tsconfig.build.esm.json (1)
4-4: LGTM! Consistent module configuration across packages
The changes mirror those in the exceptions package, maintaining consistency in the ESM build configuration across the project.
Let's verify the impact of the removed references section mentioned in the summary:
Also applies to: 10-10
✅ Verification successful
Let me try a different approach to verify the references:
LGTM! No impact from references removal
Based on the verification results:
- The TypeScript configs in the networks package don't contain any project references, showing they were already removed.
- The package is imported normally across the codebase through the package name
@injectivelabs/networks, not through project references. - The module configuration change to
NodeNextaligns with the package's role as a dependency for other packages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for TypeScript project references and potential circular dependencies
# Find all tsconfig files
echo "Checking for TypeScript project references..."
fd tsconfig.*.json | xargs cat | jq -r 'select(.references != null) | .references[]?.path' 2>/dev/null
# Check for potential import cycles between packages
echo "Checking for package dependencies..."
fd package.json -x jq -r '.dependencies // {} | keys[]' {} \; | sort | uniq -c
Length of output: 29836
Script:
#!/bin/bash
# Check for TypeScript project references in the networks package
echo "Checking networks package TypeScript configs..."
fd tsconfig -p packages/networks -x cat {} \;
# Check for any imports of the networks package
echo -e "\nChecking for networks package imports..."
rg "@injectivelabs/networks" --type ts
Length of output: 6445
packages/utils/tsconfig.build.json (1)
6-7: Verify module system choice against PR objectives
The PR title mentions "esm build" but the configuration specifies CommonJS modules. This seems contradictory. Is this intentional, perhaps as:
- A transitional step towards ESM?
- Part of a dual module build setup?
Let's check if there are other ESM-related configurations:
✅ Verification successful
CommonJS configuration is correct as part of dual module build setup
The configuration is correct. The evidence shows a dual-module build setup where:
tsconfig.build.jsonfiles configure CommonJS output todist/cjs- Parallel
tsconfig.build.esm.jsonfiles configure ESM output todist/esm
This is a common pattern for libraries that support both module systems, where the same source code is compiled twice with different module targets. The PR's "esm build" refers to adding ESM support alongside the existing CommonJS build, not replacing it.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for ESM-related TypeScript configurations
rg -g "tsconfig*.json" "module.*:.*es|moduleResolution.*:.*node"
# Check for package.json "type": "module" fields
fd package.json --exec rg -l "\"type\".*:.*\"module\""
Length of output: 2444
Script:
#!/bin/bash
# Let's check the actual content of package.json files to see if they have "type": "module"
# and check for any ESM-related build configurations
fd package.json -t f -p "packages/*" -x cat {} \; | grep -A 1 '"type":\|"module":'
# Also check for any ESM output configurations in tsconfig files
rg -g "tsconfig*.json" '"outDir"|"module".*:.*"commonjs"'
Length of output: 4330
packages/networks/tsconfig.build.json (1)
5-6: Verify dual module build setup
The output directory "./dist/cjs" suggests this might be part of a dual CJS/ESM build setup. If so, we should expect a corresponding ESM build configuration.
Let's check the build setup:
Also applies to: 7-7
✅ Verification successful
Dual module build setup confirmed
The codebase has a proper dual CJS/ESM build configuration:
- ESM build config exists at
packages/networks/tsconfig.build.esm.json - Build scripts include both
build:cjsandbuild:esmtargets - Post-build step correctly sets up package.json files for both CJS and ESM outputs in
dist/cjsanddist/esmdirectories
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for ESM build configurations
fd tsconfig --exec rg -l "outDir.*:.*esm"
# Look for dual module build scripts
fd package.json --exec rg "build:.*esm"
Length of output: 8644
packages/sdk-ts/tsconfig.build.json (1)
5-8: Consider documenting the module system transition strategy
The systematic addition of CommonJS configuration across packages, combined with the PR title mentioning "esm build", suggests a significant architectural transition. Consider:
- Adding documentation about the module system transition strategy
- Updating the README with information about dual module support (if applicable)
- Clarifying which packages are being deprecated and their migration paths
Let's check for existing documentation:
packages/exceptions/tsconfig.build.json (2)
5-8: LGTM: CommonJS module configuration
The module configuration is correctly set up for CommonJS output:
"module": "commonjs"matches the CJS output directory"moduleResolution": "node"is the appropriate resolution strategy
5-6: Verify ESM build configuration
Given that this PR is about "ESM build", and this file configures CommonJS output, there should be a corresponding tsconfig.build.esm.json for ESM builds.
✅ Verification successful
ESM configuration is properly set up
The package is correctly configured for dual CJS/ESM output:
- ESM config uses
NodeNextmodule with output to./dist/esm - CJS config uses
commonjsmodule with output to./dist/cjs - Package.json exports field properly configures both formats
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for ESM config file and its module settings
fd tsconfig.build.esm.json packages/exceptions/ --exec cat {} \; | jq -r 'select(.compilerOptions.module != null) | .compilerOptions.module'
Length of output: 154
Script:
#!/bin/bash
# Check the output directory in ESM config to verify dual package setup
fd tsconfig.build.esm.json packages/exceptions/ --exec cat {} \; | jq -r 'select(.compilerOptions.outDir != null) | .compilerOptions.outDir'
# Also check package.json for exports field to confirm dual package setup
fd package.json packages/exceptions/ --exec cat {} \; | jq -r 'select(.exports != null) | .exports'
Length of output: 772
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts (6)
26-29: LGTM! Improved readability of class declaration
The multi-line formatting enhances code readability while maintaining the same functionality.
98-101: LGTM! Added type safety for transaction hash return
The type assertion to string correctly matches the expected transaction hash return type of eth_sendTransaction.
154-157: LGTM! Added type safety for signature return
The type assertion to string correctly matches the expected signature return type of eth_signTypedData_v4.
212-212: LGTM! Added type safety for personal signature
The type assertion to string correctly matches the expected signature return type of personal_sign.
70-72: LGTM! Added type safety for ethereum.request result
The type assertion to string[] matches the expected return type of eth_requestAccounts.
Let's verify the return type in the Phantom wallet documentation:
✅ Verification successful
Type assertion to string[] is consistent with codebase patterns
The search results show that the eth_requestAccounts method is consistently typed as returning string[] across multiple wallet implementations in the codebase, including Metamask, WalletConnect, TrustWallet, BitGet, and others. The type assertion in the Phantom implementation follows the same established pattern used throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for eth_requestAccounts method documentation or usage
rg -A 5 "eth_requestAccounts.*return" --type ts
Length of output: 49
Script:
#!/bin/bash
# Let's try a broader search for eth_requestAccounts usage patterns
rg "eth_requestAccounts" --type ts -B 2 -A 2
# Also search for similar wallet connection patterns
rg "request.*accounts" --type ts -B 2 -A 2
Length of output: 6330
283-283: Verify callback implementation matches the type signature
The callback type allows for both AccountAddress and string[], but the implementation only uses the first account (accounts[0]). This might cause confusion as the type suggests the entire array of accounts could be passed to the callback.
Let's check if other wallet implementations handle this consistently:
✅ Verification successful
Callback implementation matches the type signature
Looking at the implementation, while the callback type allows for both AccountAddress and string[], the code handles this correctly:
- The
listenerfunction receives an array of accounts from theaccountsChangedevent - If accounts exist, it calls the callback with the first account (
accounts[0]) which satisfies theAccountAddresstype - As a fallback, it attempts to get addresses and uses the first one
- The type signature
AccountAddress | string[]correctly represents both possible callback scenarios, even though the implementation chooses to consistently provide a single address
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar onAccountChange implementations
ast-grep --pattern 'onAccountChange(callback: $TYPE) { $$$
$$.on("accountsChanged", $LISTENER)
}'
Length of output: 101
Script:
#!/bin/bash
# Let's try a broader search for onAccountChange implementations
rg -A 10 "onAccountChange.*callback" --type ts
# Also search for accountsChanged event handling
rg -A 5 "accountsChanged" --type ts
Length of output: 16638
Script:
#!/bin/bash
# Let's look at the Phantom implementation specifically
rg -A 15 "onAccountChange.*callback.*AccountAddress.*string" deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts
Length of output: 151
Script:
#!/bin/bash
# Let's look at the entire Phantom implementation file
cat deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts
Length of output: 8768
packages/utils/src/test-utils/msgs.ts (2)
1-2: LGTM! Import changes align with ESM refactoring.
The migration from external to local imports is a good practice that reduces external dependencies.
Let's verify if there are other opportunities for localizing imports:
✅ Verification successful
Let me analyze the results. The search shows multiple files still importing from '@injectivelabs/utils', but we need to understand which of these imports could be localized like the ones in the file under review. Let's check what utilities are available locally:
Let's check the actual exports from the local utils package to understand what utilities are available:
Let me check one more thing to verify the BigNumber classes since they weren't visible in the direct exports:
Based on all the gathered information, I can now generate the final response:
The import changes are correct and align with the available local utilities.
The changes in the imports are valid as the local utils package provides all the necessary utilities:
DEFAULT_GAS_LIMITandDEFAULT_GAS_PRICEare exported fromconstants.tsBigNumberInBaseis available as a local class inclasses/BigNumber/
Looking at the broader codebase usage:
- Many files still import from '@injectivelabs/utils', but this is expected as the ESM refactoring is likely being done incrementally
- The local implementations match the functionality of the external package
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other @injectivelabs imports that could potentially be localized
rg --type ts "from '@injectivelabs/utils'" -l | while read -r file; do
echo "=== $file ==="
rg "from '@injectivelabs/utils'" "$file"
done
Length of output: 21137
Script:
#!/bin/bash
# Check what utilities are available in the local utils package
echo "=== Contents of packages/utils/src/ ==="
fd . "packages/utils/src/" -t f -x echo "{}"
echo -e "\n=== Exported utilities from packages/utils/src/ ==="
rg "export \{.*\}" "packages/utils/src/index.ts" || true
echo -e "\n=== Available constants ==="
rg "export const" "packages/utils/src/constants.js" || true
Length of output: 1414
Script:
#!/bin/bash
# Check exports from constants.ts and index.ts
echo "=== Exports from constants.ts ==="
rg "export const|export enum" "packages/utils/src/constants.ts" || true
echo -e "\n=== Exports from index.ts ==="
rg "export \{|export \*|export type" "packages/utils/src/index.ts" || true
# Check if BigNumber and other commonly imported utilities are available locally
echo -e "\n=== BigNumber related exports ==="
rg "export (class|interface|type) (BigNumber|BigNumberInBase|BigNumberInWei)" "packages/utils/src/classes/BigNumber/" || true
Length of output: 1495
Script:
#!/bin/bash
# Check BigNumber exports from classes/index.ts
echo "=== BigNumber exports from classes/index.ts ==="
rg "export.*BigNumber" "packages/utils/src/classes/index.ts" || true
# Check actual BigNumber class implementations
echo -e "\n=== BigNumber class implementations ==="
for file in packages/utils/src/classes/BigNumber/*.ts; do
if [[ "$file" != *".spec."* ]]; then
echo "=== $file ==="
rg "^(export )?(default )?class" "$file" || true
fi
done
Length of output: 2075
75-78: Verify BigNumberInBase precision handling for fee calculations.
While the switch to BigNumberInBase aligns with the refactoring, please ensure:
- It maintains the same precision guarantees as the previous
BigNumberimplementation - The multiplication order (
gas * DEFAULT_GAS_PRICE) doesn't lead to precision loss
Let's check the implementation and usage of BigNumberInBase:
✅ Verification successful
Let me gather more information about BigNumberInBase implementation and its relationship with BigNumber:
Based on the results, I can now provide a final response:
BigNumberInBase maintains precision guarantees for fee calculations
The implementation shows that BigNumberInBase directly extends the BigNumber class and preserves all precision-related operations through proper inheritance. The multiplication order in gas * DEFAULT_GAS_PRICE is consistent with other fee calculations throughout the codebase, and the class properly handles method chaining for mathematical operations while maintaining the base unit precision.
Key observations:
BigNumberInBaseinherits all precision handling fromBigNumber- The implementation includes proper method overrides that maintain precision by returning new
BigNumberInBaseinstances - Similar fee calculations are used consistently across the codebase, confirming the pattern's reliability
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check BigNumberInBase implementation for precision handling
ast-grep --pattern 'class BigNumberInBase {
$$$
}'
# Check other fee calculations using BigNumberInBase
rg -A 3 "BigNumberInBase.*DEFAULT_GAS" --type ts
Length of output: 1374
Script:
#!/bin/bash
# Check BigNumberInBase definition and inheritance
rg -A 5 "class BigNumberInBase" --type ts
# Check if BigNumberInBase extends BigNumber
rg "extends.*BigNumber" --type ts
# Look for BigNumberInBase constructor and precision handling
ast-grep --pattern 'new BigNumberInBase($$$)'
# Check for any documentation or comments about precision
rg "BigNumberInBase.*precision|precision.*BigNumberInBase" --type ts
Length of output: 11494
packages/ts-types/package.json (2)
7-7: LGTM: ESM configuration is properly set up
The addition of "type": "module" is correctly configured alongside the existing dual ESM/CJS build setup and exports field.
58-60: LGTM: Correct dependency categorization
Moving shx to devDependencies is appropriate as it's only used in build scripts and not required at runtime.
packages/exceptions/package.json (2)
7-7: LGTM: ESM configuration is properly set up
The addition of "type": "module" is correctly configured alongside the existing dual ESM/CJS build setup and exports field.
59-63: Verify the impact of removed dependencies
The removal of @injectivelabs/grpc-web and @injectivelabs/ts-types dependencies needs verification to ensure no breaking changes.
✅ Verification successful
Since there were no matches found for imports of the removed dependencies in the source files, it appears safe to remove these dependencies. However, let's verify if there are any TypeScript type references or usages that might not be directly imported.
Let's check the actual content of these files that have GRPC references to understand if they still depend on the removed packages.
Let's check the content of the remaining files to ensure there are no direct dependencies on the removed packages.
Based on the analysis of the codebase, I can now provide a final response:
Dependencies can be safely removed
The removed dependencies @injectivelabs/grpc-web and @injectivelabs/ts-types are not being used in the codebase. While there are GRPC-related code and types in the exceptions package, they are self-contained within the package and don't rely on the external dependencies:
- The GRPC-related code (GrpcUnaryRequestException) uses only local types and enums
- All error types and codes are defined locally in the package
- No direct imports or usage of the removed dependencies were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining imports of removed dependencies
# Check for any remaining imports of removed packages
echo "Checking for remaining imports of removed packages..."
rg -l '@injectivelabs/(grpc-web|ts-types)' ./packages/exceptions/src/
# Check if any types from ts-types are still being used
echo "Checking for any types from ts-types..."
ast-grep --pattern 'import { $_ } from "@injectivelabs/ts-types"' ./packages/exceptions/src/
Length of output: 372
Script:
#!/bin/bash
# Check for any potential type references or usages
echo "Checking for any references to types or classes that might have been from these packages..."
rg -l -i '(grpc|GrpcException|TsType)' ./packages/exceptions/src/
# Check the git diff to see what was actually removed
echo "Checking git diff for removed dependencies..."
git diff HEAD~1 HEAD -- packages/exceptions/package.json
Length of output: 1246
Script:
#!/bin/bash
# Check content of files with GRPC references
echo "Checking GrpcUnaryRequestException.ts..."
cat ./packages/exceptions/src/exceptions/exceptions/GrpcUnaryRequestException.ts
echo -e "\nChecking types.ts..."
cat ./packages/exceptions/src/types.ts
echo -e "\nChecking utils.ts..."
cat ./packages/exceptions/src/utils.ts
Length of output: 3097
Script:
#!/bin/bash
echo "Checking base.ts..."
cat ./packages/exceptions/src/exceptions/base.ts
echo -e "\nChecking error types and codes..."
cat ./packages/exceptions/src/exceptions/types/codes.ts
cat ./packages/exceptions/src/exceptions/types/context.ts
Length of output: 34989
packages/networks/package.json (2)
6-6: LGTM: ESM configuration is properly set up
The addition of "type": "module" is correctly configured alongside the existing dual ESM/CJS build setup and exports field.
59-63: Verify the impact of removed dependencies
The removal of @injectivelabs/exceptions and @injectivelabs/utils dependencies needs verification:
- Check if any exception handling code needs to be migrated
- Verify that
INJ_DENOMand other utilities have been properly replaced with local implementations
✅ Verification successful
Let me verify the usage of INJ_DENOM to ensure it's properly defined locally since it was previously from @injectivelabs/utils.
Let me check for any remaining exception usages with a different pattern to ensure we haven't missed anything.
Dependencies removal verified successfully
Based on the verification results:
- No imports of
@injectivelabs/exceptionsor@injectivelabs/utilswere found in the codebase - No exception handling code from the removed package is present
INJ_DENOMhas been properly defined locally inchainInfos.tsand is used consistently- No other utilities from the removed packages are being used
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining imports and verify replacements
# Check for any remaining imports of removed packages
echo "Checking for remaining imports of removed packages..."
rg -l '@injectivelabs/(exceptions|utils)' ./packages/networks/src/
# Check if any exceptions are still being used
echo "Checking for exception usage..."
ast-grep --pattern 'throw new $exception' ./packages/networks/src/
# Check for INJ_DENOM usage
echo "Checking for INJ_DENOM usage..."
rg 'INJ_DENOM' ./packages/networks/src/
Length of output: 746
Script:
#!/bin/bash
# Check the full context of INJ_DENOM definition and usage
echo "Checking INJ_DENOM definition and context..."
rg -A 5 -B 5 'const INJ_DENOM' ./packages/networks/src/
# Check for any other potential utility imports or usages
echo "Checking for other utility usages..."
rg '@injectivelabs/utils' ./packages/networks/src/
Length of output: 904
Script:
#!/bin/bash
# Check for any exception class definitions or usages
echo "Checking for exception related code..."
rg -l 'Exception|Error' ./packages/networks/src/
# Check the content of any files that might contain exceptions
echo "Checking content of potential exception files..."
find ./packages/networks/src/ -type f -exec grep -l 'Exception\|Error' {} \; | xargs cat
Length of output: 338
packages/utils/package.json (2)
79-80: Verify dependency version compatibility
Notable dependency changes:
- Downgrade of @injectivelabs/exceptions
- Addition of @injectivelabs/networks
- Upgrade of store2
Please ensure these version changes are intentional and compatible.
Also applies to: 85-85
✅ Verification successful
Dependencies are aligned with the ecosystem
Based on the analysis of package.json files across the repository, the @InjectiveLabs dependencies are consistently using compatible versions (1.14.33 and 1.14.34-beta series). The changes in the utils package maintain version alignment with other packages in the monorepo, ensuring compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for breaking changes in store2 between versions
gh api repos/nbubna/store/releases --jq '.[].body' | rg -i "breaking" -A 5
# Verify exceptions package compatibility
gh api repos/InjectiveLabs/injective-ts/releases --jq '.[].body' | rg -i "@injectivelabs/exceptions.*1\.14\.33" -A 5
Length of output: 193
Script:
#!/bin/bash
# Let's check for any version-related dependencies in the repository
fd package.json --exec cat {} | jq -r '.dependencies | select(. != null) | to_entries[] | select(.key | contains("@injectivelabs")) | "\(.key)=\(.value)"'
# Check if there are any direct imports or usage of these packages
rg -l "@injectivelabs/exceptions|@injectivelabs/networks" --type ts --type js
# Let's also check the previous version in git history
git show HEAD~1:packages/utils/package.json | jq -r '.dependencies | select(. != null) | to_entries[] | select(.key | contains("@injectivelabs")) | "\(.key)=\(.value)"'
Length of output: 14982
6-6: Verify ESM compatibility across dependent packages
The addition of "type": "module" indicates a migration to ES modules. This change requires careful verification of compatibility with dependent packages.
✅ Verification successful
Let me gather more information about the ESM migration impact by checking for .mjs and .cjs files, as well as examining import statements.
Based on the gathered information, I can now provide the final response:
ESM migration appears to be properly implemented
The utils package's migration to ESM is well-structured:
- All imports/exports consistently use
.jsextensions - No
.mjsor.cjsfiles present, indicating a clean ESM implementation - Dependent packages are all within the monorepo ecosystem
- CommonJS
require()usage is limited to configuration files and utilities, not in the main package code
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential CommonJS require statements that might break
rg "require\(" --type js --type ts
# Look for potential dual package hazard
fd "package.json" --exec jq -r 'select(.type == "module" and .exports != null) | .name' 2>/dev/null
Length of output: 1107
Script:
#!/bin/bash
# Check for .mjs and .cjs files which might indicate mixed module systems
fd "\.(mjs|cjs)$"
# Check import statements in the utils package
rg "^import .* from" packages/utils/
# Check export statements in the utils package
rg "^export " packages/utils/
# Check package.json files that depend on @injectivelabs/utils
fd "package.json" --exec jq -r 'select(.dependencies."@injectivelabs/utils" != null) | .name' 2>/dev/null
Length of output: 8959
package.json (2)
17-17: Verify patch-package implementation
The addition of patch-package to build and bootstrap scripts indicates a need for dependency patches. Please ensure:
- All patches are documented
- Patches are temporary solutions with tracking issues for proper fixes
Also applies to: 38-38
✅ Verification successful
Patches are present and appear to be for hardware wallet integrations
The patches are properly documented in the patches directory and are specifically targeting hardware wallet integration libraries (Ledger and Trezor):
- Ledger patches: hw-app-cosmos, hw-app-eth, hw-transport, hw-transport-webhid, hw-transport-webusb
- Trezor patches: connect-web
- WalletConnect patches: ethereum-provider
The patches appear to be fixing TypeScript declaration issues (modifying .d.ts files) to ensure proper type exports, which is a common and acceptable use case for patch-package.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing patches
fd "^.*\.patch$" patches/
# Look for patch documentation
rg -l "patch-package" -g "!package*.json" -g "!yarn.lock"
Length of output: 412
Script:
#!/bin/bash
# Check patch contents to verify documentation and nature of patches
for patch in patches/*.patch; do
echo "=== $patch ==="
head -n 20 "$patch"
echo -e "\n"
done
# Look for any patch-related documentation in markdown files
rg -l "patch" -g "*.md"
Length of output: 66746
73-74: Review major version upgrades
Several dependencies have significant version upgrades:
- lerna: 6.6.1 → 8.1.9 (major version jump)
- jest and related packages
- typescript: 5.1.1 → 5.7.2
Please ensure these updates have been thoroughly tested, especially lerna which has breaking changes between v6 and v8.
Also applies to: 92-95
packages/sdk-ts/package.json (1)
11-11: Verify ESM compatibility with existing exports
The addition of "type": "module" needs to be verified against the extensive exports configuration to ensure all module resolution paths work correctly.
✅ Verification successful
Based on the search results, I can see that the codebase extensively uses ES modules with import statements throughout, and there are no CommonJS require() patterns in the main package code - the only require() usages are in configuration files (jest.config.js) and utility scripts (etc/ folder) which are not part of the main package.
ESM compatibility is properly maintained across the codebase
The addition of "type": "module" aligns with the codebase's existing module system:
- All source files consistently use ES module imports/exports
- No CommonJS require() patterns in the main package code
- Configuration files that need CommonJS are appropriately placed outside the main package
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential CommonJS patterns
rg "require\(" --type js --type ts
# Look for potential import/require mixing
rg "require\.|import |import\(" --type js --type ts
Length of output: 69491
packages/sdk-ts/jest.config.js (1)
1-3: Ensure Jest is configured to support ES modules
Converting the Jest configuration file to ES module syntax requires that Jest is properly configured to handle ESM. Please verify that Jest and related tooling are set up correctly to support ES modules.
packages/exceptions/jest.config.js (1)
1-3: Ensure Jest is configured to support ES modules
Similar to the change in packages/sdk-ts/jest.config.js, please verify that Jest is properly configured to handle ES modules for this package.
packages/ts-types/jest.config.js (1)
1-3: Ensure Jest is configured to support ES modules
As with the other packages, confirm that Jest is correctly configured to support ES modules in this package.
packages/networks/jest.config.js (1)
1-3: Ensure Jest is configured to support ES modules
Consistent with the changes in other packages, please verify that Jest is set up to handle ES modules in this package.
packages/utils/jest.config.js (1)
Line range hint 1-9: Verify ESM configuration for Jest
The transition to ESM syntax looks good, but we should verify the following:
- Ensure jest is configured to handle ESM modules
- Confirm that
tsconfig.build.esm.jsonexists and is properly configured for ESM
✅ Verification successful
Let me gather more information about the Jest ESM configuration.
ESM configuration for Jest is properly set up
The verification shows that the ESM configuration is correctly implemented:
- Root jest.config.js has proper ESM support with
preset: 'ts-jest/presets/default-esm'anduseESM: truein ts-jest transform - The
tsconfig.build.esm.jsonexists in the utils package with correct ESM settings (NodeNext module, ESNext target) - The extensionsToTreatAsEsm is configured to handle
.tsfiles
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for ESM configuration files and settings
echo "Checking for tsconfig.build.esm.json..."
fd "tsconfig.build.esm.json" --type f
echo "Checking package.json for type:module..."
fd "package.json" --type f --exec jq '.type'
Length of output: 1532
Script:
#!/bin/bash
# Check Jest configuration in package.json and root jest.config
echo "Checking Jest configuration in package.json files..."
fd "package.json" --type f --exec jq '.jest'
echo "\nChecking root jest.config.js..."
cat jest.config.js
echo "\nChecking utils package tsconfig..."
cat packages/utils/tsconfig.build.esm.json
Length of output: 7728
packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts (1)
2-3:
Standardize test-utils import path across test files
There's an inconsistency in how test-utils is imported across test files:
- This file uses:
@injectivelabs/utils/test-utils - Other files use:
deprecated/test-utils/dist/cjs
We should standardize on one approach, preferably using the non-deprecated ESM-compatible path shown in this file.
packages/sdk-ts/src/core/modules/permissions/msgs/MsgDeleteNamespace.spec.ts (1)
3-3: Verify deprecation of @injectivelabs/test-utils package
The import path change aligns with the PR objective of package deprecation. However, we should ensure this migration is properly documented.
packages/sdk-ts/src/core/modules/permissions/msgs/MsgRevokeNamespaceRoles.spec.ts (1)
3-3: Same import path update as in MsgDeleteNamespace.spec.ts
packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts (1)
3-4: LGTM! Improved error handling with standardized error code mapping
The change enhances error handling by using grpcErrorCodeToErrorCode for consistent error code mapping across the codebase.
Also applies to: 42-42
✅ Verification successful
Error handling implementation verified and consistent with codebase patterns
The error handling implementation in ChainGrpcPeggyApi.ts follows the standard pattern used across the codebase:
- Properly imports and uses
grpcErrorCodeToErrorCodefor error code mapping - Correctly implements error handling with
GrpcUnaryRequestExceptionfor both GRPC-specific and general errors - Maintains consistent error context and module information
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify consistent error handling pattern across similar API classes
ast-grep --pattern $'class ChainGrpc$_Api extends BaseGrpcConsumer {
$$$
catch (e: unknown) {
if (e instanceof $$$GrpcWebError) {
throw new GrpcUnaryRequestException($$$, {
code: grpcErrorCodeToErrorCode(e.code),
$$$
})
}
$$$
}
}'
Length of output: 275
Script:
#!/bin/bash
# Let's try a different approach to verify error handling patterns
# First, find all Chain GRPC API files
fd "ChainGrpc.*Api.ts" packages/sdk-ts/src
# Then check for error handling patterns in these files
rg "grpcErrorCodeToErrorCode|GrpcUnaryRequestException" -A 2 -B 2 packages/sdk-ts/src
Length of output: 72323
Script:
#!/bin/bash
# Let's check the error handling pattern in Chain GRPC API files
rg "catch \(e: unknown\)" -A 5 -B 2 packages/sdk-ts/src/client/chain/grpc/ChainGrpc.*Api.ts
Length of output: 191
Script:
#!/bin/bash
# Let's check the error handling pattern in Chain GRPC API files specifically
rg "catch \(e: unknown\)" -A 5 -B 2 packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts
# Also check imports and usage of grpcErrorCodeToErrorCode in the file
rg "grpcErrorCodeToErrorCode|GrpcUnaryRequestException" -A 2 -B 2 packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts
Length of output: 1144
packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespaceRoles.spec.ts (1)
3-3: LGTM! Import path update aligns with package deprecation.
The updated import path for mockFactory maintains functionality while following the package reorganization.
packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawValidatorCommission.spec.ts (1)
2-2: LGTM! Import path update is consistent.
The mockFactory import path update aligns with the package reorganization while maintaining all test functionality.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)
3-3: LGTM! Import path update is consistent.
The mockFactory import path update aligns with the package reorganization.
packages/sdk-ts/src/core/modules/feegrant/msgs/MsgRevokeAllowance.spec.ts (1)
1-2: LGTM! Import changes align with ESM standards
The changes correctly:
- Use the new utils path structure
- Include .js extension for ESM compatibility
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgMint.spec.ts (1)
3-3: LGTM! Import path change aligns with ESM refactoring.
The updated import path and .js extension usage are consistent with ESM module standards.
✅ Verification successful
Import path is correct and mockFactory is properly exported
The verification confirms that:
mockFactoryis exported frompackages/utils/src/test-utils/mocks/index.ts- The import path
@injectivelabs/utils/test-utilscorrectly maps to this location - The export is being used across multiple test files in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the new import path exists and is properly exported
fd -e ts -e js "test-utils" | grep -l "mockFactory.*export"
Length of output: 59
Script:
#!/bin/bash
# First, let's find all test-utils files
fd "test-utils"
# Then, let's search for mockFactory in the codebase
rg "mockFactory" -l
# Finally, let's look for the actual export of mockFactory
ast-grep --pattern 'export const mockFactory'
Length of output: 8383
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts (1)
3-3: LGTM! Import path change aligns with ESM refactoring.
The updated import path is consistent with ESM module standards.
packages/sdk-ts/src/core/modules/gov/msgs/MsgVote.spec.ts (1)
2-2: LGTM! Import path change aligns with ESM refactoring.
The updated import path and .js extension usage are consistent with ESM module standards.
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgCreateDenom.spec.ts (1)
2-2: LGTM! Verify package structure for test utilities
The import path change aligns with the ESM refactoring objective. The file already follows proper ESM conventions with .js extensions.
✅ Verification successful
Import path change is correct and properly configured
The import path @injectivelabs/utils/test-utils is correctly configured in the packages/utils/package.json with proper exports for both ESM and CJS formats. The path is being used consistently across multiple test files in the SDK package, indicating this is the new standardized location for test utilities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the new package structure and imports
# Check if the new test-utils path exists and is properly exported
fd -t f "index.ts|index.js" -p "@injectivelabs/utils/test-utils"
Length of output: 183
Script:
#!/bin/bash
# Let's first check if the test-utils exists in the utils package
fd -t f "test-utils" packages/utils
# Check for any exports or references to test-utils
rg -g "*.{ts,js}" "test-utils" packages/utils
# Check if there are any other files importing from this path
rg -g "*.{ts,js}" "@injectivelabs/utils/test-utils"
Length of output: 8811
Script:
#!/bin/bash
# Let's check the actual location of test-utils in the repository
fd -t f "mockFactory.ts" packages
# Also check if there are any package.json files that might export test-utils
rg -g "package.json" "test-utils" packages
Length of output: 929
packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts (1)
2-2: LGTM! Import path change is consistent
The modification follows the same pattern as other files, maintaining consistency across the codebase.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (1)
3-3: LGTM! Verify broader refactoring impact
The import changes are consistent with the ESM refactoring pattern seen across the codebase.
✅ Verification successful
Let me check the content of the remaining file to verify if it needs to be updated for consistency.
Import changes are consistent across the codebase
The remaining occurrence of @injectivelabs/test-utils is actually commented out and not in active use, confirming that the import changes have been consistently applied throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the consistency of import changes across the codebase
# Check for any remaining old import paths that might have been missed
rg -l "@injectivelabs/test-utils" --type ts
Length of output: 105
Script:
#!/bin/bash
# Check the content of the file to see the import statement
rg "@injectivelabs/test-utils" packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts -A 2
Length of output: 285
packages/sdk-ts/src/core/modules/exchange/msgs/MsgWithdraw.spec.ts (1)
3-3: LGTM! Import path updated for ESM compatibility.
The change is part of the package reorganization and maintains ESM compatibility with the .js extension.
Let's verify the package structure and dependencies:
✅ Verification successful
Let me gather more information to verify the import path change.
Let me gather one final piece of information to verify the test-utils location in the utils package.
Import path change is correct and properly configured
The verification confirms that:
- The
test-utilssubpath is properly exported in the utils package's package.json - The module exists at the correct location:
packages/utils/src/test-utils - The import path
@injectivelabs/utils/test-utilsis consistent with the package's exports configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify package structure and dependencies
# Check if test-utils is properly exported from utils package
cat package.json | jq '.exports["./test-utils"]' || echo "test-utils not exported"
# Verify no remaining old imports
rg -l "@injectivelabs/test-utils"
Length of output: 665
Script:
#!/bin/bash
# Check the actual location of test-utils in the utils package
fd test-utils -t f
# Check the exports field in utils package.json
fd package.json --exec sh -c 'echo "=== {} ===" && cat {} | jq ".exports"' 2>/dev/null
# Check for any other files using the new import path
rg -l "@injectivelabs/utils/test-utils"
Length of output: 19034
Script:
#!/bin/bash
# Check for test-utils directory and its contents in the utils package
fd -t d test-utils packages/utils
fd -t f . packages/utils/src/test-utils 2>/dev/null
Length of output: 230
packages/sdk-ts/src/core/modules/insurance/msgs/MsgUnderwrite.spec.ts (1)
3-3: LGTM! Import path updated consistently.
The change aligns with the package reorganization pattern seen across the codebase.
packages/sdk-ts/src/core/modules/bank/msgs/MsgSend.spec.ts (1)
1-3: LGTM! Changes are consistent with ESM migration
The import changes maintain consistency with other files and properly follow ESM conventions with .js extensions.
packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts (1)
2-3: LGTM: Import changes align with ESM migration
The changes correctly implement:
- ESM compatibility by using the .js extension
- Updated test utilities path following package reorganization
Let's verify no test behavior changes:
✅ Verification successful
Import changes are correct and test functionality is preserved
The verification confirms:
- The test file correctly uses
mockFactoryfrom the new path - The test maintains its original functionality, using
mockFactoryfor test data (derivative market ID and injective address) - All test assertions remain intact and properly validate the message's proto, amino, EIP-712, and web3 transformations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify mockFactory exports between old and new paths
# Note: This helps ensure the reorganization didn't affect test data
rg -A 3 "export.*mockFactory" "@injectivelabs/utils/test-utils"
Length of output: 135
Script:
#!/bin/bash
# Let's first find the actual location of mockFactory
fd mockFactory
# Then check its content and exports
rg -A 3 "export.*mockFactory"
Length of output: 317
Script:
#!/bin/bash
# Let's verify the test file's content to ensure it uses mockFactory correctly
cat "packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts"
# Also check if there are any other files using mockFactory to ensure consistency
rg -l "@injectivelabs/utils/test-utils.*mockFactory"
Length of output: 2266
packages/sdk-ts/src/core/modules/gov/msgs/MsgDeposit.spec.ts (1)
2-3: LGTM: Consistent import updates
The changes maintain consistency with other files in the ESM migration and package reorganization.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts (1)
1-2: LGTM: Import changes maintain consistency
The changes align with the ESM migration pattern seen across other test files.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (2)
1-2: LGTM: ESM syntax properly implemented
The .js extension in the import statement correctly follows ESM requirements.
2-2: Verify test utility migration impact
The mockFactory import path has been updated as part of the test utilities reorganization. Let's verify this change is consistent across the codebase.
✅ Verification successful
Import path migration is consistent across the codebase
The verification shows that the migration of mockFactory from @injectivelabs/test-utils to @injectivelabs/utils/test-utils is consistent across the codebase. There is only one commented-out reference to the old import path in ChainGrpcGovApi.spec.ts, which doesn't affect the functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining old import paths
# and verify consistency of new import paths
echo "Checking for old import paths..."
rg "@injectivelabs/test-utils" --type ts
echo "Verifying consistency of new import paths..."
rg "@injectivelabs/utils/test-utils" --type ts
Length of output: 9060
packages/sdk-ts/src/core/modules/exchange/msgs/MsgExternalTransfer.spec.ts (1)
1-3: LGTM: Import statements follow ESM conventions
The changes maintain consistency with the ESM migration pattern seen across the codebase:
- Local imports include
.jsextension - Test utilities import path updated to the new location
packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts (1)
1-3: LGTM: Consistent with ESM migration pattern
The changes follow the established pattern of ESM migration and test utilities reorganization.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)
3-4: LGTM: Improved error handling with standardized error codes
The introduction of grpcErrorCodeToErrorCode enhances error handling consistency across gRPC APIs.
Also applies to: 39-39, 66-66
packages/sdk-ts/src/core/modules/staking/msgs/MsgCancelUnbondingDelegation.spec.ts (1)
3-3: LGTM: Updated import path as part of package standardization
The import path change aligns with the PR's objective of package deprecation and standardization.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgIncreasePositionMargin.spec.ts (1)
2-2: LGTM: Updated import path as part of package standardization
The import path change aligns with the PR's objective of package deprecation and standardization.
packages/sdk-ts/src/core/modules/staking/msgs/MsgEditValidator.spec.ts (1)
2-2: Verify consistent usage of new test-utils import path
The import path change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the package deprecation objective. Let's ensure this change is consistent across the codebase.
✅ Verification successful
Let me analyze the results. I see that most test files have been updated to use the new import path @injectivelabs/utils/test-utils, but there's one test file still using the old import path: packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts. Let me verify this specific file to ensure it's not a false positive.
Import path migration is consistent across active codebase
The old import path is only found in commented-out code and yarn.lock files. All active test files consistently use the new import path @injectivelabs/utils/test-utils, including the file under review. This change is properly aligned across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining old import paths and verify consistency
# Check for old import paths
echo "Files still using old import path:"
rg -l "@injectivelabs/test-utils"
# Check new import path usage
echo "Files using new import path:"
rg -l "@injectivelabs/utils/test-utils"
Length of output: 5490
Script:
#!/bin/bash
# Check the specific content of the file still using old import
echo "Content of ChainGrpcGovApi.spec.ts showing imports:"
rg -A 3 "import.*@injectivelabs/test-utils" packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts
Length of output: 409
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAuctionApi.ts (2)
3-4: LGTM: Improved error handling with standardized error code conversion
The addition of grpcErrorCodeToErrorCode improves error handling consistency.
48-48: Verify error code conversion implementation
The error handling now uses grpcErrorCodeToErrorCode for consistent error code conversion. Let's verify the implementation of this function.
Also applies to: 74-74
✅ Verification successful
The verification results show that:
-
The
grpcErrorCodeToErrorCodefunction is implemented inpackages/exceptions/src/exceptions/types/codes.tsas a simple type conversion function that takes a gRPC error code and returns it as aGrpcErrorCodetype. -
The function is consistently used across all gRPC API clients in the codebase for error handling, with over 150 occurrences showing uniform usage pattern:
code: grpcErrorCodeToErrorCode(e.code).
Error code conversion implementation verified
The implementation follows a consistent pattern across the codebase and provides type-safe error code conversion from gRPC to internal error codes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the implementation and usage of grpcErrorCodeToErrorCode
# Find the implementation
echo "Implementation of grpcErrorCodeToErrorCode:"
rg -A 10 "export const grpcErrorCodeToErrorCode"
# Check consistent usage across files
echo "Usage of grpcErrorCodeToErrorCode in error handling:"
rg "grpcErrorCodeToErrorCode\(.*\.code\)"
Length of output: 23814
packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelBinaryOptionsOrders.spec.ts (1)
2-2: LGTM: Consistent with package deprecation changes
The import path update is consistent with the broader package deprecation effort seen in other test files.
packages/sdk-ts/src/core/modules/insurance/msgs/MsgCreateInsuranceFund.spec.ts (1)
2-3: LGTM: Consistent ESM-compliant changes
The changes maintain consistency with the ESM migration:
- Added
.jsextension for local imports - Updated mockFactory import path matching the package restructuring
packages/sdk-ts/src/core/tx/eip712/eip712.spec.ts (1)
1-4: LGTM: ESM-compliant imports with package restructuring
The changes align with ESM requirements and package restructuring:
- Updated mockFactory import path
- Added
.jsextension for local imports - Maintained ESM-style imports for all dependencies
Let's verify the package restructuring impact:
✅ Verification successful
Import path changes are consistent across the codebase
The verification shows that @injectivelabs/utils/test-utils is consistently used across all test files in the repository, confirming that the import path change in eip712.spec.ts aligns with the standard pattern used throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if test-utils package is marked as deprecated
gh api repos/injectivelabs/test-utils/packages | jq '.[] | select(.name=="test-utils") | .metadata.deprecation_notice'
# Verify if utils/test-utils is the new standard across the monorepo
rg -g '*.{ts,js}' "from '@injectivelabs/(utils/test-utils|test-utils)'" .
Length of output: 9221
packages/sdk-ts/src/client/chain/grpc/ChainGrpcIbcApi.ts (1)
3-4: LGTM! Error handling standardization looks good.
The changes improve error handling consistency by using grpcErrorCodeToErrorCode for standardized error code transformation across gRPC errors. This aligns well with the refactoring objectives.
Also applies to: 44-44, 78-78
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.ts (1)
3-4: LGTM! Consistent error handling implementation.
The error handling changes follow the same standardization pattern as other files, ensuring consistent error code transformation across the codebase.
Also applies to: 60-60, 88-88
packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts (2)
2-2: LGTM! Import path update is consistent with package reorganization.
The mockFactory import path has been updated to align with the new package structure.
2-2: Verify the availability of the new import path.
Let's ensure the new import path is properly set up and accessible.
✅ Verification successful
Import path is valid and properly configured
The import path @injectivelabs/utils/test-utils is valid and accessible. The mockFactory is correctly exported from packages/utils/src/test-utils/mocks/index.ts and is being used properly in the test file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the new mockFactory import path exists and is accessible
# Check if the new path exists
fd -t f "test-utils.(ts|js)" packages/utils
# Check for any remaining old import paths that might need updating
rg -l "@injectivelabs/test-utils"
Length of output: 655
Script:
#!/bin/bash
# Let's check for mockFactory in utils package and its exports
rg -A 5 "mockFactory" packages/utils
# Also check if there's any test-utils file in the entire repo
fd -t f "test-utils"
# Check the actual import statement in the file
cat "packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts"
Length of output: 4586
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMetaApi.ts (1)
3-4: LGTM! Consistent error handling improvement
The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves code consistency and provides better error reporting.
Also applies to: 38-38, 64-64, 92-92
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts (1)
Line range hint 71-98: Address skipped EIP712 comparison tests
The skipped test suite for EIP712 comparison needs attention. The TODO comment suggests incomplete implementation.
Let's check if there are other skipped EIP712 tests that need attention:
Would you like help implementing these EIP712 comparison tests?
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcWeb3GwApi.ts (1)
12-12: LGTM: Improved error handling consistency
Good improvement in error handling by using grpcErrorCodeToErrorCode to standardize error codes across the codebase.
Also applies to: 105-105
packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts (1)
3-3: LGTM: Updated to new package path
Good update to use the new @injectivelabs/utils/test-utils package instead of the old path.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotLimitOrder.spec.ts (1)
1-2: Verify test-utils package deprecation impact
The import path change from @injectivelabs/test-utils to @injectivelabs/utils/test-utils aligns with the PR's objective of package deprecation. However, we should ensure this change is consistently applied across all test files.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotMarketOrder.spec.ts (1)
1-2: LGTM - Changes consistent with package reorganization
The changes mirror those in MsgCreateSpotLimitOrder.spec.ts and are part of the broader package reorganization.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts (1)
43-43: Verify error code mapping consistency
The introduction of grpcErrorCodeToErrorCode standardizes error code handling. Let's ensure this pattern is consistently applied across all gRPC API classes.
Also applies to: 73-73, 103-103
✅ Verification successful
Error code mapping is consistently applied across gRPC APIs
The search results show that grpcErrorCodeToErrorCode is consistently used across all gRPC API classes in the codebase, including the ChainGrpcAuctionApi and other related APIs. There are no instances of direct e.code usage found, confirming that the error code standardization is properly implemented throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent error handling across gRPC API classes
# Check for direct e.code usage that might have been missed
echo "Checking for direct error code usage..."
rg "code: e.code" "packages/sdk-ts/src/client/**/grpc/"
# Verify consistent usage of grpcErrorCodeToErrorCode
echo "Verifying grpcErrorCodeToErrorCode usage..."
rg "grpcErrorCodeToErrorCode\(e.code\)" "packages/sdk-ts/src/client/**/grpc/"
Length of output: 475
Script:
#!/bin/bash
# Let's first find the correct path structure
fd "ChainGrpcAuctionApi.ts"
# Then check for direct e.code usage
echo "Checking for direct error code usage..."
rg "code: e\.code" --type ts
# Verify consistent usage of grpcErrorCodeToErrorCode
echo "Verifying grpcErrorCodeToErrorCode usage..."
rg "grpcErrorCodeToErrorCode\(e\.code\)" --type ts
# Look for other error handling patterns
echo "Checking other error handling patterns..."
rg "catch.*\(e\).*{" -A 3 --type ts
Length of output: 23270
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts (2)
1-1: LGTM: Import path update aligns with package deprecation.
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is consistent with the PR's objective.
Line range hint 15-15: Verify if tests should remain skipped.
The entire test suite is currently skipped. Please verify if these tests should be re-enabled or if there's a specific reason for skipping them.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeLimitOrder.spec.ts (1)
2-2: LGTM: Import path update is consistent.
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is consistent with the package deprecation strategy.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts (1)
2-2: LGTM: Import path update is consistent.
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' aligns with the package deprecation strategy.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeMarketOrder.spec.ts (1)
2-2: Verify consistent usage of new test-utils import path
The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' appears to be part of package reorganization.
✅ Verification successful
Let me generate additional verification scripts to get a clearer picture of the import statements.
The first command will show us the actual import statements being used, while the second will help us understand how test-utils is configured in the package dependencies. This will give us better context about whether the import path change is correct and consistent.
Import path change is correctly implemented across the codebase
The verification shows that all test files are consistently using the new import path @injectivelabs/utils/test-utils, with only one commented-out instance of the old path in ChainGrpcGovApi.spec.ts. The change in MsgCreateDerivativeMarketOrder.spec.ts aligns with the codebase-wide standardization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent usage of new test-utils import path across test files
# Test: Search for any remaining old import paths
rg -l "@injectivelabs/test-utils"
# Test: Confirm adoption of new import path
rg -l "@injectivelabs/utils/test-utils"
Length of output: 5344
Script:
#!/bin/bash
# Get actual import statements for test-utils to see the exact usage
rg "import.*@injectivelabs/.*test-utils" --type ts
# Check package.json for dependencies
cat packages/sdk-ts/package.json | grep -A 5 -B 5 "test-utils"
Length of output: 8914
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.spec.ts (2)
1-2: LGTM! Import changes align with ESM standards
The changes correctly implement ESM compatibility:
- Using .js extension in imports
- Updated mockFactory import path follows the package reorganization
Line range hint 4-122: Verify test coverage for binary options limit order message
The test suite comprehensively covers all message formats and transformations. However, let's verify that no edge cases are missed.
✅ Verification successful
Based on the comprehensive analysis of the implementation and test files, I can now provide the final response:
Test coverage for binary options limit order message is comprehensive
The test suite adequately covers all essential aspects:
- Proper proto message generation with correct field formatting
- Data structure conversion with proper type annotations
- Amino encoding with correct snake case transformation
- EIP-712 type and value generation
- Proper decimal handling through the
amountToCosmosSdkDecAmountutility
The implementation includes proper value transformations and formatting through the number utilities, and the test cases verify both the structure and the numerical precision of the transformed values. No edge cases are missed as the message structure follows the same pattern as other order types, with proper validation handled at the protocol level.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any untested binary options limit order scenarios
# Look for other binary options limit order related tests
rg -l "MsgCreateBinaryOptionsLimitOrder" --type ts
# Check for any TODO/FIXME comments related to testing
rg -i "todo|fixme" --type ts | grep -i "binary.*options.*limit.*order"
Length of output: 460
Script:
#!/bin/bash
# Let's analyze the implementation and test coverage more thoroughly
# Check the implementation file content
cat packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.ts
# Look for any validation or edge case handling in the implementation
rg -A 5 "validate|check|throw" packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.ts
# Check if there are any other test files that might contain edge cases
fd "binary.*options.*limit.*order.*spec" -I
Length of output: 4002
Script:
#!/bin/bash
# Let's check for validation in the parent class and related utilities
# Check MsgBase class for any validation
cat packages/sdk-ts/src/core/modules/MsgBase.ts
# Check number utilities for validation
cat packages/sdk-ts/src/utils/numbers.ts
# Look for any error handling or validation in the exchange module
rg -A 5 "throw|error|validate|check" packages/sdk-ts/src/core/modules/exchange/
Length of output: 24999
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsMarketOrder.spec.ts (1)
1-2: LGTM! Consistent with limit order test changes
The import changes maintain consistency with the limit order tests and ESM standards.
packages/sdk-ts/src/client/abacus/grpc/AbacusGrpcApi.ts (2)
4-4: LGTM: Standardized error code handling
The addition of grpcErrorCodeToErrorCode aligns with the codebase-wide initiative to standardize gRPC error handling.
39-39: Verify error code mapping compatibility
The replacement of direct error code usage with grpcErrorCodeToErrorCode improves consistency, but we should verify that all possible gRPC error codes are properly mapped.
Also applies to: 75-75, 111-111
✅ Verification successful
The error code mapping is properly implemented and consistent
The grpcErrorCodeToErrorCode function properly maps gRPC error codes to the GrpcErrorCode enum which contains all standard gRPC error codes (0-16). The implementation is consistent across all API clients and properly handles error code translation from gRPC to application-specific error codes.
The mapping is used consistently in error handling blocks across all gRPC API clients to translate error codes in a standardized way:
if (e instanceof GrpcWebError) {
throw new GrpcUnaryRequestException(new Error(e.toString()), {
code: grpcErrorCodeToErrorCode(e.code),
context: '...',
contextModule: '...'
})
}🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of direct gRPC error code usage that might need updating
rg -A 2 "instanceof.*GrpcWebError" | rg "code: e\.code"
# Search for error code mapping implementation
ast-grep --pattern 'function grpcErrorCodeToErrorCode($_) {
$$$
}'
Length of output: 128
Script:
#!/bin/bash
# Let's try a broader search for the error code mapping function
rg -l "grpcErrorCodeToErrorCode"
# Search for the error code mapping implementation with a more flexible pattern
ast-grep --pattern 'grpcErrorCodeToErrorCode'
# Look for any error handling patterns with GrpcWebError
rg -A 5 "GrpcWebError"
Length of output: 94776
Script:
#!/bin/bash
# Let's look for the error code mapping implementation
rg -A 10 "grpcErrorCodeToErrorCode.*=.*" packages/exceptions/src/exceptions/types/codes.ts
# Also check for any gRPC error code definitions or enums
rg -A 5 "enum.*Error"
Length of output: 65924
Script:
#!/bin/bash
# Let's look for the error code mapping implementation in the codes.ts file
cat packages/exceptions/src/exceptions/types/codes.ts
Length of output: 27630
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts (1)
3-4: LGTM: Consistent error handling improvements
The import changes align with the standardized error handling approach being implemented across the codebase.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTradingApi.ts (2)
3-4: LGTM: Standardized error handling imports
The addition of grpcErrorCodeToErrorCode aligns with the codebase-wide standardization of gRPC error handling.
39-39: LGTM: Consistent error handling implementation
The error handling has been standardized across both methods using grpcErrorCodeToErrorCode, improving consistency and maintainability.
Also applies to: 158-158
packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.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.
✅ Verification successful
Let me gather more information to verify if there are any inconsistencies in the import paths.
Let me check if there are any imports using the new path pattern to ensure consistency.
Import path change is part of a broader migration pattern
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is part of a consistent migration pattern across the codebase. The new path is already being used in numerous test files, while there's only one remaining occurrence of the old path in ChainGrpcGovApi.spec.ts (which appears to be commented out). This confirms that the import path change is aligned with the package deprecation effort.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the consistency of import path changes across the codebase
rg -l "@injectivelabs/test-utils"
Length of output: 609
Script:
#!/bin/bash
# Check the actual import statements in the found files, excluding yarn.lock
rg "@injectivelabs/test-utils" --type ts -A 1 -B 1
Length of output: 417
Script:
#!/bin/bash
# Check for imports using the new path pattern
rg "@injectivelabs/utils/test-utils" --type ts -A 1 -B 1
Length of output: 24678
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthZApi.ts (2)
3-3: LGTM: Standardized error handling imports
The addition of grpcErrorCodeToErrorCode maintains consistency with the codebase-wide standardization of gRPC error handling.
70-70: LGTM: Uniform error handling implementation
The error handling has been standardized across all three methods (fetchGrants, fetchGranterGrants, fetchGranteeGrants) using grpcErrorCodeToErrorCode, maintaining consistency with the rest of the codebase.
Also applies to: 109-109, 148-148
packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (2)
3-4: LGTM: Improved error handling imports
The addition of grpcErrorCodeToErrorCode aligns with the standardization of error handling across the codebase.
45-45: LGTM: Consistent error code transformation
The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves consistency and maintainability.
Also applies to: 78-78, 108-108, 138-138
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.spec.ts (1)
2-2: 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/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts (1)
2-2: LGTM: Updated test utilities import path
The import path change to '@injectivelabs/utils/test-utils' is consistent with the package deprecation effort.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)
3-3: LGTM: Import path update aligns with package deprecation.
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is consistent with the PR's objective of package reorganization.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.ts (2)
3-4: LGTM: Improved error handling imports.
The addition of grpcErrorCodeToErrorCode aligns with standardizing error handling across the codebase.
43-43: LGTM: Consistent error code standardization.
The use of grpcErrorCodeToErrorCode across all methods ensures consistent error code handling throughout the API.
Also applies to: 73-73, 105-105, 144-144, 183-183
packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.spec.ts (3)
3-3: LGTM: Import path update aligns with package deprecation.
The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is consistent with the PR's objective of package reorganization.
Line range hint 15-23: Consider enhancing test error handling.
Similar to IndexerGrpcArchiverApi.spec.ts, the error handling pattern needs improvement across all tests.
Also applies to: 33-47, 52-60, 69-77, 86-94, 103-111, 120-128, 137-145, 154-162, 171-179, 188-196
Line range hint 33-47: Address the skipped test for fetchModuleState.
The test is currently skipped due to timeout issues with large module state. Consider:
- Breaking down the test into smaller chunks
- Implementing timeout handling
- Using mock data for testing
Let's analyze the module state size:
packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts (1)
3-4: LGTM! Standardized error handling imports.
The addition of grpcErrorCodeToErrorCode and reorganization of imports improves code organization and error handling consistency.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts (1)
3-4: LGTM! Standardized error handling imports.
The addition of grpcErrorCodeToErrorCode and reorganization of imports aligns with the codebase-wide standardization effort.
packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts (1)
2-2: LGTM! More specific import path.
The import path change to ../../utils/utf8.js improves module organization by directly referencing the specific utility file.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.spec.ts (1)
2-2: LGTM! Import path updated as part of package reorganization.
The change aligns with the refactoring effort to reorganize utility packages.
jest.config.js (2)
90-90: LGTM! Added mapping for crypto library compatibility.
The mapping ensures Jest correctly resolves crypto-es imports to crypto-js, maintaining compatibility while updating dependencies.
185-188: Verify the impact of transforming @noble/secp256k1.
The transformation pattern has been updated to process @noble/secp256k1 while ignoring other node_modules. This could affect build time and test performance.
✅ Verification successful
Transform pattern for @noble/secp256k1 is necessary for cryptographic functionality
The transformation pattern for @noble/secp256k1 is justified as the package is extensively used throughout the codebase, particularly in critical cryptographic and transaction-related functionality:
- Core cryptographic operations in
packages/sdk-ts/src/utils/crypto.ts - Transaction handling in
packages/sdk-ts/src/utils/transaction.ts - Account management and signing in multiple files under
packages/sdk-ts/src/core/accounts/ - Message broadcasting in
packages/wallets/wallet-core/src/broadcaster/MsgBroadcaster.ts
While this transformation may slightly impact build time, it's essential for proper functioning of the cryptographic features in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if @noble/secp256k1 is actually used in the codebase
rg -l "@noble/secp256k1"
# Check the import patterns to understand usage
ast-grep --pattern 'import $_ from "@noble/secp256k1"'
Length of output: 106
Script:
#!/bin/bash
# Check package.json for dependencies
cat package.json | jq '.dependencies["@noble/secp256k1"], .devDependencies["@noble/secp256k1"]'
# Search for any require statements of the package
rg -l "require.*@noble/secp256k1"
# Look for actual usage patterns in JavaScript/TypeScript files
rg -l "secp256k1" --type js --type ts
# Check if there are any test files using this package
fd "test|spec" -e js -e ts -x rg -l "secp256k1" {}
Length of output: 997
packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts (1)
3-4: LGTM! Enhanced error handling imports.
Added grpcErrorCodeToErrorCode for standardized error code conversion.
packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (1)
7-9: LGTM: Improved error handling
The use of grpcErrorCodeToErrorCode standardizes error code handling across the application, making error handling more consistent and maintainable.
Also applies to: 80-80
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/PrivateKey.ts (1)
254-257: LGTM: Consistent callback type
The callback type update aligns with other wallet strategy implementations. The empty implementation is appropriate for a private key-based wallet where account changes aren't possible.
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1)
247-247: Callback type and implementation mismatch
Similar to the Leap wallet implementation, there's a mismatch between the callback type and its implementation. The type suggests support for array of accounts but the implementation only passes a single account.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.spec.ts (1)
3-3: LGTM! Verify the new import path.
The import path change for mockFactory aligns with the package reorganization.
✅ Verification successful
Import path is valid and widely used across the codebase
The import path @injectivelabs/utils/test-utils is verified to be correct and extensively used across the codebase. The search results show:
- The
mockFactoryexists in the utils package atpackages/utils/src/test-utils/ - The same import path is consistently used in numerous test files across the codebase (60+ files)
- The import is part of a standardized pattern across all test files in the SDK
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the new import path exists and is accessible
fd -t f "test-utils" -x echo "Found test utils at: {}"
Length of output: 54
Script:
#!/bin/bash
# Let's try a broader search for the mockFactory and test-utils
rg -l "mockFactory"
# Also search for the specific import path
rg "@injectivelabs/utils/test-utils"
# Check if there's any test-utils.ts file
fd "test-utils.ts"
Length of output: 13727
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/BitGet/index.ts (2)
67-67: LGTM! Type assertions improve type safety.
The added type assertions for API responses enhance type safety and make the code more maintainable.
Also applies to: 96-96, 152-152, 207-207, 221-221, 239-239
278-278: LGTM! Callback type enhancement.
The updated callback type for onAccountChange now correctly handles both single account and array responses, improving flexibility.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.ts (2)
3-3: LGTM! Added error handling utility import.
The import of grpcErrorCodeToErrorCode supports standardized error handling.
75-75: LGTM! Standardized error handling.
Consistent use of grpcErrorCodeToErrorCode across all methods improves error handling reliability and maintainability.
Also applies to: 134-134, 186-186, 234-234, 272-272, 331-331
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts (1)
281-281: Verify the impact of the callback type change
The callback type has been broadened to accept both AccountAddress and string[]. This change might require updates in consuming code that expects only AccountAddress.
✅ Verification successful
The callback type change is consistent with the codebase
The search results show that the onAccountChange callback type (account: AccountAddress | string[]) is already widely adopted across multiple wallet strategy implementations in both current and deprecated packages. Only two implementations (Torus and TrustWallet) use the narrower AccountAddress type, but they are empty implementations. The change in the Metamask strategy aligns with the common pattern used throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing implementations of onAccountChange callback
rg -A 2 "onAccountChange\(" --type typescript
Length of output: 82
Script:
#!/bin/bash
# Search for existing implementations of onAccountChange callback using ripgrep without file type restriction
rg -A 2 "onAccountChange\("
# Also search for any usage of the callback parameter
rg "callback\(" "deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/"
# Search for any imports or references to AccountAddress type
rg "AccountAddress" "deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/"
Length of output: 7290
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (1)
26-29: Changes mirror Metamask implementation
The changes in this file are identical to those in the Metamask implementation, maintaining consistency across wallet strategies.
Also applies to: 68-70, 96-99, 152-155, 210-210, 224-224, 239-242, 281-281
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts (1)
4-4: Verify error monitoring compatibility
The introduction of grpcErrorCodeToErrorCode standardizes error handling, which is good. However, this change might affect error monitoring systems that rely on the original gRPC error codes.
Also applies to: 60-60, 89-89, 120-120, 149-149, 212-212, 257-257, 291-291
✅ Verification successful
No impact on error monitoring systems
The grpcErrorCodeToErrorCode function is a simple type conversion that maintains the original error codes. Looking at its implementation in packages/exceptions/src/exceptions/types/codes.ts, it's just a pass-through function that converts the numeric error code to a typed enum value without modifying the actual code value. This means existing error monitoring systems will continue to receive the same error codes as before.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other error monitoring or handling patterns
rg "GrpcUnaryRequestException.*code:" --type typescript
# Search for potential error code consumers
rg "catch.*GrpcWebError.*code" --type typescript
Length of output: 178
Script:
#!/bin/bash
# Search for error monitoring patterns without file type restriction
rg "GrpcUnaryRequestException.*code"
# Search for error code transformations
rg "grpcErrorCodeToErrorCode"
# Search for GrpcWebError handling
rg "catch.*GrpcWebError"
# Look for error monitoring or logging implementations
ast-grep --pattern 'function grpcErrorCodeToErrorCode($_) { $$$ }'
Length of output: 26198
Script:
#!/bin/bash
# Look for the implementation of grpcErrorCodeToErrorCode
cat packages/exceptions/src/exceptions/types/codes.ts
# Search for any error monitoring or logging systems
rg "monitoring" --type-not test
rg "logger" --type-not test
Length of output: 27748
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTransactionApi.ts (1)
13-15: LGTM! Consistent error handling improvements
The changes standardize error code handling across all methods by using grpcErrorCodeToErrorCode. This improves error handling consistency and makes the error codes more reliable.
Also applies to: 101-101, 181-181, 252-252, 310-310, 336-336
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmApi.ts (1)
3-4: LGTM! Standardized error handling
The changes consistently implement standardized error code handling using grpcErrorCodeToErrorCode across all methods. This improves error handling reliability and maintainability.
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: LGTM! Consistent error handling implementation.
The standardization of error handling using grpcErrorCodeToErrorCode is consistently applied across all methods, improving error reporting reliability.
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/ChainGrpcStakingApi.spec.ts (2)
3-3: LGTM! Import path updated correctly.
The mockFactory import path has been updated to reflect the new package organization.
Line range hint 214-234: Investigate skipped test.
The fetchDelegation test is currently skipped. Please investigate why this test is skipped and either:
- Remove the skip if the test is ready to be enabled
- Add a comment explaining why it's skipped
- Create a ticket to track the implementation if it's pending
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)
3-4: LGTM: Improved error handling with standardized error codes
The addition of grpcErrorCodeToErrorCode enhances error handling consistency across the codebase.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (2)
4-4: LGTM: Consistent error handling implementation
The error handling changes align with the standardization across the codebase.
70-70: Consider extracting error handling logic
Similar to IndexerGrpcExplorerApi, the error handling pattern is duplicated across methods.
Also applies to: 99-99, 180-180, 231-231, 286-286, 344-344, 372-372, 452-452, 531-531, 559-559, 632-632
packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.ts (1)
3-4: LGTM: Consistent error handling implementation
The error handling changes align with the standardization across the codebase.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.ts (2)
4-4: Consistent error handling improvement across the API
The standardization of error handling using grpcErrorCodeToErrorCode improves error code consistency and type safety across the entire API surface.
Also applies to: 67-67, 96-96, 150-150, 182-182, 268-268, 369-369, 441-441, 524-524, 635-635, 698-698, 746-746, 798-798, 863-863, 901-901, 932-932
Line range hint 201-202: Well-structured deprecation with clear alternatives
Good practice on deprecation handling:
- Clear deprecation notice using JSDoc
- Explicit error message directing users to the new method
- Replacement methods (V2 versions) are provided
Also applies to: 879-880
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.ts (1)
3-3: Consistent error handling implementation
The error handling changes follow the same pattern as other files, demonstrating:
- Systematic approach to error standardization
- Consistent use of
grpcErrorCodeToErrorCode - Improved type safety in error handling
Also applies to: 52-52, 98-98, 144-144, 190-190, 242-242, 289-289, 324-324, 356-356, 416-416, 464-464, 504-504, 558-558, 595-595, 623-623, 655-655, 693-693, 751-751, 803-803, 840-840, 894-894, 940-940, 989-989
packages/exceptions/src/exceptions/types/codes.ts (2)
3-21: Well-structured gRPC error code enumeration
The GrpcErrorCode enum follows standard gRPC error codes, providing a type-safe way to handle gRPC errors.
798-799: Clean type system integration
The integration of GrpcErrorCode into the ErrorCode type union and the update of GRPC_REQUEST_FAILED constant is clean and maintains type safety.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.ts (1)
3-3: LGTM! Consistent error handling improvements
The implementation of grpcErrorCodeToErrorCode across all error handling blocks aligns with the codebase-wide standardization effort. This improves error handling consistency and maintainability.
Also applies to: 50-50, 87-87, 124-124, 174-174, 224-224, 272-272, 320-320, 367-367
packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts (1)
3-4: LGTM! Standardized error handling implementation
The implementation of grpcErrorCodeToErrorCode across all error handling blocks is consistent with the codebase-wide improvements.
Also applies to: 43-43, 71-71, 134-134, 164-164, 194-194, 231-231, 258-258, 288-288, 320-320
packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (2)
3-4: LGTM: Import changes align with error handling improvements
The addition of grpcErrorCodeToErrorCode and reorganization of imports support the standardized error handling implementation.
49-49: LGTM: Consistent error handling improvements across all methods
The standardization of error handling using grpcErrorCodeToErrorCode across all methods improves maintainability and ensures consistent error code mapping.
Let's verify the error code mapping implementation:
Also applies to: 85-85, 120-120, 152-152, 188-188, 222-222, 251-251, 288-288
✅ Verification successful
Error code mapping implementation is consistent and well-structured
The verification shows:
- The
grpcErrorCodeToErrorCodefunction is properly implemented inpackages/exceptions/src/exceptions/types/codes.ts - The function is consistently used across all gRPC API classes in the codebase (150+ occurrences)
- The error handling pattern is uniform, mapping gRPC error codes to internal error codes in catch blocks
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the implementation of grpcErrorCodeToErrorCode and its usage
# Check the implementation of grpcErrorCodeToErrorCode
rg -A 10 "export const grpcErrorCodeToErrorCode" --type ts
# Verify consistent usage across other gRPC API classes
rg "grpcErrorCodeToErrorCode\(.*code\)" --type ts
Length of output: 23620
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts
Show resolved
Hide resolved
| // @ts-ignore | ||
| this.storage = store.namespace(namespace) |
There was a problem hiding this comment.
Avoid using @ts-ignore - consider type-safe alternatives
Using @ts-ignore suppresses type checking which could mask potential runtime issues. Consider these type-safe alternatives:
- Add proper type definitions:
- // @ts-ignore
- this.storage = store.namespace(namespace)
+ this.storage = store.namespace(namespace) as StoreAPI- Or create a custom type declaration file for store2 if needed:
// store2.d.ts
declare module 'store2' {
export interface StoreAPI {
get(key: string): unknown;
set(key: string, value: unknown): void;
// ... other methods
}
export function namespace(ns: string): StoreAPI;
}
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Leap.ts
Show resolved
Hide resolved
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/TrustWallet/index.ts
Show resolved
Hide resolved
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/TrustWallet/index.ts
Show resolved
Hide resolved
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.spec.ts
Show resolved
Hide resolved
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/WalletConnect.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
packages/sdk-ts/src/utils/crypto.ts (3)
Line range hint
28-38: Add validation for private key lengthWhile the implementation is correct, it's missing validation for private key length and format.
export const privateKeyToPublicKey = (privateKey: Uint8Array): Uint8Array => { + if (privateKey.length !== 32) { + throw new Error('Private key must be 32 bytes') + } return secp256k1.getPublicKey(privateKey, true) } export const privateKeyHashToPublicKey = ( privateKeyHash: string, ): Uint8Array => { + if (!privateKeyHash.match(/^(0x)?[0-9a-fA-F]{64}$/)) { + throw new Error('Invalid private key format') + } const privateKey = privateKeyHash.startsWith('0x') ? privateKeyHash.slice(2) : privateKeyHash return secp256k1.getPublicKey(Buffer.from(privateKey, 'hex'), true) }
82-91: Improve validation and documentation for public key handlingThe function name suggests it only handles compressed keys, but it actually handles both compressed and uncompressed formats. Additionally, there's minimal validation of input format.
+/** + * Handles both compressed (33 bytes) and uncompressed (64/65 bytes) public keys + * @param startsWith02Or03 - Hex string of public key + * @returns Decompressed public key without '04' prefix + * @throws Error if input format is invalid + */ export function decompressPubKey(startsWith02Or03: string) { + if (!startsWith02Or03.match(/^([0-9a-fA-F]{66}|[0-9a-fA-F]{128}|[0-9a-fA-F]{130})$/)) { + throw new Error('Invalid public key format') + } const testBuffer = Buffer.from(startsWith02Or03, 'hex') if (testBuffer.length === 64) startsWith02Or03 = '04' + startsWith02Or03 const point = secp256k1.ProjectivePoint.fromHex( Buffer.from(testBuffer).toString('hex'), ) const decompressed = point.toHex(false) if (!decompressed.startsWith('04')) return decompressed return decompressed.slice(2) }
93-107: Enhance documentation and error handlingWhile the implementation is correct, it would benefit from better documentation and more descriptive error messages.
+/** + * Derives an Ethereum address from a public key + * @param pubKey - Public key as Uint8Array + * @param sanitize - If true, handles both compressed and uncompressed formats + * @returns 20-byte Ethereum address + * @throws Error if public key length is invalid + */ export const publicKeyToAddress = function ( pubKey: Uint8Array, sanitize: boolean = false, ): Uint8Array { if (sanitize && pubKey.length !== 64) { pubKey = secp256k1.ProjectivePoint.fromHex(pubKey) .toRawBytes(false) .slice(1) } if (pubKey.length !== 64) { - throw new Error('Expected pubKey to be of length 64') + throw new Error(`Invalid public key length: ${pubKey.length} bytes. Expected: 64 bytes`) } return keccak256(Buffer.from(pubKey)).subarray(-20) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
jest.config.js(2 hunks)package.json(5 hunks)packages/exceptions/src/exceptions/types/codes.ts(2 hunks)packages/sdk-ts/package.json(2 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts(1 hunks)packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts(2 hunks)packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts(1 hunks)packages/sdk-ts/src/utils/crypto.ts(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts
🚧 Files skipped from review as they are similar to previous changes (7)
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts
- packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts
- jest.config.js
- packages/exceptions/src/exceptions/types/codes.ts
- packages/sdk-ts/package.json
- packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts
- package.json
🔇 Additional comments (1)
packages/sdk-ts/src/utils/crypto.ts (1)
14-24: LGTM! Encoding issue has been fixed
The implementation now correctly handles binary data by using WordArray.create directly instead of converting to UTF-8 string first.
This PR
@injectivelabs/wallet-tspackage,@injectivelabs/test-utilspackage and moves the content in the@injectivelabs/utilspackage,patch-package) for some npm packages that are impossible to change to work properly with ESM,With this, we should conclude the packages being up to the latest standards and are fully ESM compatible.
Summary by CodeRabbit
Release Notes
New Features
addHexPrefixandremoveHexPrefixutility functions for handling hexadecimal strings.Improvements
grpcErrorCodeToErrorCodefor transforming error codes.getStdFeeForTokenandgetStdFeeFromObjectto utilizeBigNumberInBasefor improved precision.Deprecations
getAddressFromInjectiveAddressas deprecated; users are encouraged to usegetEthereumAddressinstead.Bug Fixes
mockFactoryacross multiple test files to ensure correct mock data generation.These updates enhance the functionality, reliability, and maintainability of the codebase, improving user experience and developer efficiency.