-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor: canary esm build and deprecating packages #535
base: dev
Are you sure you want to change the base?
Refactor: canary esm build and deprecating packages #535
Conversation
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe changes represent a comprehensive refactoring and modernization of the Injective Protocol's TypeScript SDK and related packages. The modifications span multiple areas, including module system transitions, error handling improvements, cryptographic utility updates, and dependency management. Key focus areas include migrating to ECMAScript modules, standardizing error code processing, updating cryptographic functions, and removing the 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. 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 9
🔭 Outside diff range comments (10)
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)
Line range hint
16-180
: Improve test robustness and error handling.The test suite could be improved in several ways:
- Tests currently swallow errors and only log them, which means they'll pass even when API calls fail
- No validation of error scenarios
- Missing test coverage for edge cases (e.g., invalid dates, malformed account addresses)
Consider refactoring the tests to:
- Remove try-catch blocks and let Jest handle the errors
- Add negative test cases
- Add validation for edge cases
Example refactor for one test:
test('fetchHistoricalBalance', async () => { - try { - const response = await indexerGrpcArchiverApi.fetchHistoricalBalance({ - account, - resolution, - }) - - expect(response).toBeDefined() - expect(response).toEqual( - expect.objectContaining< - ReturnType< - typeof IndexerGrpcArchiverTransformer.grpcHistoricalBalanceResponseToHistoricalBalances - > - >(response), - ) - } catch (e) { - console.error( - 'IndexerGrpcArchiverApi.fetchHistoricalBalance => ' + - (e as any).message, - ) - } + const response = await indexerGrpcArchiverApi.fetchHistoricalBalance({ + account, + resolution, + }) + + expect(response).toBeDefined() + expect(response).toEqual( + expect.objectContaining< + ReturnType< + typeof IndexerGrpcArchiverTransformer.grpcHistoricalBalanceResponseToHistoricalBalances + > + >(response), + ) +}) + +test('fetchHistoricalBalance handles invalid account', async () => { + await expect( + indexerGrpcArchiverApi.fetchHistoricalBalance({ + account: 'invalid-account', + resolution, + }) + ).rejects.toThrow() })packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)
Line range hint
15-33
: Improve test robustness and error handling.The current test implementation has several issues:
- Test will pass even if an error occurs (errors are only logged)
- Missing assertion count to ensure all assertions are executed
- Missing error scenarios
Consider this improved implementation:
describe('IndexerGrpcAccountPortfolioApi', () => { test('fetchAccountPortfolio', async () => { + expect.assertions(2); try { const response = await indexerGrpcPortfolioApi.fetchAccountPortfolio( injectiveAddress, ) expect(response).toBeDefined() expect(response).toEqual( expect.objectContaining< ReturnType< typeof IndexerGrpcAccountPortfolioTransformer.accountPortfolioResponseToAccountPortfolio > >(response), ) } catch (e) { - console.error( - 'IndexerGrpcAccountPortfolioApi.fetchAccountPortfolio => ' + - (e as any).message, - ) + throw e } }) + + test('fetchAccountPortfolio handles errors', async () => { + expect.assertions(1); + const invalidAddress = 'invalid-address'; + + await expect( + indexerGrpcPortfolioApi.fetchAccountPortfolio(invalidAddress) + ).rejects.toThrow(); + }) })packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)
Line range hint
11-170
: Improve test error handling and coverage.The test suite has several areas for improvement:
- Tests currently catch and log errors without failing, which could mask test failures
- Error handling code is duplicated across all tests
- Missing test cases for error scenarios
Consider refactoring the tests using this pattern:
describe('OLPGrpcApi', () => { // Common error handler const handleTestError = (methodName: string) => (error: unknown) => { console.error(`OLPGrpcApi.${methodName} => ${(error as Error).message}`); throw error; // Re-throw to fail the test }; // Example of improved test structure test('fetchEpochs', async () => { const response = await dmmGrpcApi.fetchEpochs().catch(handleTestError('fetchEpochs')); expect(response).toBeDefined(); expect(response).toEqual( expect.objectContaining<ReturnType<typeof DmmGrpcTransformer.epochsResponseToEpochs>>(response), ); }); // Add error scenario tests test('fetchEpochs handles network errors', async () => { const errorApi = new OLPGrpcApi('invalid-url'); await expect(errorApi.fetchEpochs()).rejects.toThrow(); }); });packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (1)
Line range hint
78-82
: Fix incorrect error context string.The error context string in
fetchDenomAuthorityMetadata
is incorrect. It's using 'TokenFactoryDenomsFromCreator' instead of 'TokenFactoryDenomAuthorityMetadata'.Apply this fix:
throw new GrpcUnaryRequestException(new Error(e.toString()), { code: grpcErrorCodeToErrorCode(e.code), - context: 'TokenFactoryDenomsFromCreator', + context: 'TokenFactoryDenomAuthorityMetadata', contextModule: this.module, })packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (1)
Line range hint
208-223
: Update error handling in deprecated broadcastBlock method.The deprecated
broadcastBlock
method still uses the removedGeneralException
. Consider updating it to use the new error handling pattern before removal.Apply this diff to update the error handling:
- throw new GeneralException( - new Error('There was an issue broadcasting the transaction'), - ) + throw new GrpcUnaryRequestException( + new Error('There was an issue broadcasting the transaction'), + { + context: 'TxGrpcApi', + contextModule: 'broadcast-block', + }, + )packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)
Line range hint
424-426
: Remove duplicate condition check forbefore
parameter.The
before
condition is checked twice in thefetchTxs
method, which is redundant.Apply this diff to remove the duplicate check:
if (before) { request.before = before.toString() } if (startTime) { request.startTime = startTime.toString() } - if (before) { - request.before = before.toString() - } if (endTime) { request.endTime = endTime.toString() }Also applies to: 445-447
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (1)
Implement the commented out
isConditional
parameter codeThe
isConditional
parameter is actively used in the derivatives API and should be implemented in the spot API for feature parity. The implementation is already written but commented out.
- Uncomment the
isConditional
implementation in both methods- Fix the spacing in
request.isConditional =isConditional
torequest.isConditional = isConditional
🔗 Analysis chain
Line range hint
164-166
: Address commented out code forisConditional
parameter.There are commented out code blocks for the
isConditional
parameter in multiple methods. These should either be implemented or removed to maintain code cleanliness.Please verify if this feature is still needed. If it is:
- Implement the feature
- Add appropriate tests
If not, remove the commented code.Also applies to: 275-277
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if isConditional is used elsewhere in the codebase # Search for isConditional usage rg "isConditional" --type tsLength of output: 1895
Script:
#!/bin/bash # Get the full context of methods using isConditional in spot API ast-grep --pattern 'function $_($$$) { $$$ if (isConditional !== undefined) { $$$ } $$$ }' packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts # Also get the commented sections mentioned in the review rg -A 2 -B 2 "isConditional" packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.tsLength of output: 761
packages/utils/jest.config.js (1)
Line range hint
5-7
: UpdatetsConfig
totsconfig
ints-jest
configuration.The
ts-jest
configuration usestsConfig
, which has been deprecated. Update it totsconfig
to align with the latestts-jest
options.Apply this diff:
globals: { 'ts-jest': { - tsConfig: 'tsconfig.build.esm.json', + tsconfig: 'tsconfig.build.esm.json', }, },packages/exceptions/jest.config.js (1)
Line range hint
5-7
: UpdatetsConfig
totsconfig
ints-jest
configuration.Similar to the change in
packages/utils/jest.config.js
, updatetsConfig
totsconfig
in thets-jest
configuration for consistency and to use the correct option name.Apply this diff:
globals: { 'ts-jest': { - tsConfig: 'tsconfig.build.esm.json', + tsconfig: 'tsconfig.build.esm.json', }, },deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (1)
Line range hint
256-256
: Fix incorrect event listener name.The event listener is using 'leap_keystorechange' instead of 'ninji_keystorechange', which is inconsistent with the wallet type.
Apply this diff to fix the event name:
- window.addEventListener('leap_keystorechange', listener) + window.addEventListener('ninji_keystorechange', listener)
🧹 Nitpick comments (19)
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts (1)
3-4
: Consider the impact of updating deprecated packages.This file is in a deprecated package but is still receiving updates. This could mislead users into thinking the package is still maintained.
Consider either:
- Moving the actively maintained code to a new package
- Adding clear deprecation notices with migration paths for users
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)
Line range hint
35-61
: Remove commented out code.If the
fetchAccountPortfolioTokenHolders
test is no longer needed, remove it entirely. If it's still relevant, implement it properly. Keeping commented out code reduces maintainability.packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)
Line range hint
23-25
: Standardize error handling across tests.The error handling in the test suite has several inconsistencies:
- Unsafe type casting with
as any
- String concatenation instead of template literals
- Inconsistent error message formatting
Consider standardizing error handling:
// Create a typed error handler type GrpcError = Error & { code?: number; message: string }; const formatErrorMessage = (method: string, error: GrpcError) => `OLPGrpcApi.${method} failed: ${error.message}${error.code ? ` (code: ${error.code})` : ''}`; // Usage in tests } catch (error) { console.error(formatErrorMessage('fetchEpochs', error as GrpcError)); }Also applies to: 45-47, 68-71, 89-91, 112-115, 136-138, 159-162
packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (1)
2-2
: Consider documenting the ESM migration strategy.The use of '.js' extensions in imports and the consolidation of utility packages indicate a transition to ECMAScript modules. Consider:
- Documenting the migration strategy
- Updating the package.json
type
field- Adding ESM-specific export maps
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (1)
1-1
: Consider using explicit file extension for local imports.For consistency with ECMAScript modules, consider adding the
.js
extension to the local import.-import MsgCancelBinaryOptionsOrder from './MsgCancelBinaryOptionsOrder' +import MsgCancelBinaryOptionsOrder from './MsgCancelBinaryOptionsOrder.js'packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)
Line range hint
61-61
: Address TODO comment in fetchModuleState.The TODO comment in the response handling needs to be addressed for completeness.
Would you like me to help implement the proper state handling for the module state response?
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcWeb3GwApi.ts (1)
12-12
: Consider standardizing error type handling.While the error code standardization is good, consider also standardizing the error type handling. Currently,
e.type
is directly passed through while error codes are transformed.throw new TransactionException(new Error(e.toString()), { - type: e.type, + type: ErrorType.Web3Gateway, context: 'Web3Gateway.PrepareEip712', code: grpcErrorCodeToErrorCode(e.code), })Also applies to: 106-107
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (1)
Line range hint
47-48
: Consider type-safe error message checking.The current error message check uses unsafe type casting with
as any
. Consider implementing a type-safe error check.-if ((e as any)?.message === 'account address not found') { +if (e instanceof Error && e.message === 'account address not found') {Also applies to: 88-89
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts (1)
3-4
: LGTM! Consider enhancing error type checking.The standardized error handling looks good. However, in the
fetchOraclePriceNoThrow
method, consider using a more type-safe approach for checking 'object not found' errors.- if ((e as any).message.includes('object not found')) { + if (e instanceof Error && e.message.includes('object not found')) {Also applies to: 39-39, 83-83, 133-133
packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (1)
1-1
: Well-structured refactoring with consistent patterns.The changes demonstrate a well-thought-out refactoring approach with two main improvements:
- Service separation through dedicated explorer endpoints
- Standardized error handling using
grpcErrorCodeToErrorCode
The modifications are consistently applied across different modules and environments, improving maintainability and reliability.
packages/exceptions/src/exceptions/types/codes.ts (1)
23-27
: Consider adding validation in the error code conversion.The current implementation assumes the input is always a valid gRPC error code. Consider adding validation to handle invalid codes gracefully.
export const grpcErrorCodeToErrorCode = <T extends number>( grpcErrorCode: T, ): GrpcErrorCode => { - return grpcErrorCode as GrpcErrorCode + if (grpcErrorCode >= GrpcErrorCode.OK && grpcErrorCode <= GrpcErrorCode.Unauthenticated) { + return grpcErrorCode as GrpcErrorCode + } + return GrpcErrorCode.Unknown }packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.ts (1)
Line range hint
1-989
: Consider extracting the error handling pattern into a utility function.The error handling pattern is repeated across multiple methods. Consider creating a utility function to reduce duplication and improve maintainability.
private handleGrpcError(e: unknown, context: string): never { if (e instanceof InjectiveMetaRpc.GrpcWebError) { throw new GrpcUnaryRequestException(new Error(e.toString()), { code: grpcErrorCodeToErrorCode(e.code), context, contextModule: this.module, }) } throw new GrpcUnaryRequestException(e as Error, { code: UnspecifiedErrorCode, context, contextModule: this.module, }) }Usage example:
try { const response = await this.retry<MitoApi.GetVaultResponse>(() => this.client.GetVault(request), ) return IndexerGrpcMitoTransformer.vaultResponseToVault(response) } catch (e: unknown) { - if (e instanceof InjectiveMetaRpc.GrpcWebError) { - throw new GrpcUnaryRequestException(new Error(e.toString()), { - code: grpcErrorCodeToErrorCode(e.code), - context: 'GetVault', - contextModule: this.module, - }) - } - - throw new GrpcUnaryRequestException(e as Error, { - code: UnspecifiedErrorCode, - context: 'GetVault', - contextModule: this.module, - }) + this.handleGrpcError(e, 'GetVault') }packages/networks/tsconfig.build.esm.json (1)
1-1
: Consider documenting the dual module system strategy.The transition to supporting both CommonJS (via
commonjs
+node
) and ESM (viaNodeNext
) builds is a solid architectural choice. Consider adding documentation about:
- The rationale behind supporting both module systems
- How consumers should choose between CJS and ESM builds
- Any migration guides for downstream dependencies
packages/sdk-ts/src/utils/crypto.ts (2)
1-2
: Remove commented-out import statement for cleaner codebase.The commented-out import statement on line 1 is unnecessary and can be removed to keep the codebase clean.
Apply this diff:
-// import CryptoEs from 'crypto-es'
83-83
: Simplify Buffer conversion indecompressPubKey
function.In line 83, since
testBuffer
is already a Buffer, usingBuffer.from(testBuffer)
is redundant. You can simplify the code by convertingtestBuffer
directly to a hexadecimal string.Apply this diff:
- Buffer.from(testBuffer).toString('hex'), + testBuffer.toString('hex'),packages/sdk-ts/src/utils/address.ts (1)
107-111
: LGTM! Consider adding input validation.The new utility functions are well-implemented and focused. However, consider adding input validation to ensure the input is a valid hex string.
export const addHexPrefix = (hex: string) => + hex && typeof hex === 'string' && /^[0-9a-fA-F]*$/.test(hex.replace('0x', '')) ? hex.startsWith('0x') ? hex : `0x${hex}` + : throw new Error('Invalid hex string') export const removeHexPrefix = (hex: string) => + hex && typeof hex === 'string' && /^[0-9a-fA-F]*$/.test(hex.replace('0x', '')) ? hex.startsWith('0x') ? hex.slice(2) : hex + : throw new Error('Invalid hex string')deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/PrivateKey.ts (1)
254-256
: Add documentation for unsupported operation.Since private key wallets don't support account changes, consider adding a comment explaining why this operation is not implemented.
Apply this diff to improve documentation:
async onAccountChange( _callback: (account: AccountAddress | string[]) => void, ): Promise<void> { - // + // Private key wallets don't support account changes as they are bound to a single key }deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1)
245-247
: Consider standardizing the account change handling across wallet implementations.The codebase shows inconsistencies in how different wallet strategies handle account changes:
- Some implementations are empty (PrivateKey)
- Some use incorrect event names (Ninji)
- All implementations only handle single accounts despite the new type supporting arrays
Consider:
- Creating an abstract base class method that enforces consistent implementation
- Documenting why some wallets support multiple accounts while others don't
- Adding migration notes since these files are in a deprecated directory
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (1)
26-29
: Consider extracting common wallet functionality into a base class.All wallet strategy implementations share similar patterns for:
- Type assertions for ethereum.request calls
- Error handling with specific wallet exceptions
- Transaction receipt polling logic
- Account and chain ID change event handling
Consider creating a base Ethereum wallet strategy class that implements these common patterns, reducing code duplication and ensuring consistent behavior across wallet implementations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (157)
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/BitGet/index.ts
(7 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Leap.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/Base.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/hw/index.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts
(7 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts
(8 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts
(8 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/PrivateKey.ts
(1 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/TrustWallet/index.ts
(7 hunks)deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/WalletConnect.ts
(1 hunks)etc/replacements-ledger.js
(0 hunks)etc/replacements.js
(0 hunks)jest.config.js
(2 hunks)lerna.json
(0 hunks)package.json
(5 hunks)packages/exceptions/jest.config.js
(1 hunks)packages/exceptions/package.json
(1 hunks)packages/exceptions/src/exceptions/types/codes.ts
(2 hunks)packages/exceptions/tsconfig.build.esm.json
(1 hunks)packages/exceptions/tsconfig.build.json
(1 hunks)packages/networks/jest.config.js
(1 hunks)packages/networks/package.json
(1 hunks)packages/networks/src/chainInfos.ts
(1 hunks)packages/networks/src/endpoints.ts
(4 hunks)packages/networks/tsconfig.build.esm.json
(1 hunks)packages/networks/tsconfig.build.json
(1 hunks)packages/sdk-ts/jest.config.js
(1 hunks)packages/sdk-ts/package.json
(2 hunks)packages/sdk-ts/src/client/abacus/grpc/AbacusGrpcApi.ts
(4 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts
(4 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.ts
(4 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthZApi.ts
(4 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts
(9 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts
(6 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts
(12 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts
(7 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcIbcApi.ts
(3 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.ts
(6 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcMintApi.ts
(4 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcOracleApi.ts
(2 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts
(2 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts
(7 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.ts
(18 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcTendermintApi.ts
(2 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts
(5 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmApi.ts
(10 hunks)packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts
(3 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts
(8 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.ts
(9 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAuctionApi.ts
(5 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.ts
(7 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.ts
(16 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts
(12 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.ts
(3 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMetaApi.ts
(4 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.ts
(23 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcOracleApi.ts
(4 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts
(3 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts
(11 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTradingApi.ts
(3 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTransactionApi.ts
(6 hunks)packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcWeb3GwApi.ts
(2 hunks)packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts
(1 hunks)packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.ts
(11 hunks)packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts
(2 hunks)packages/sdk-ts/src/core/modules/auction/msgs/MsgBid.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/bank/msgs/MsgSend.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawDelegatorReward.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawValidatorCommission.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelBinaryOptionsOrders.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelDerivativeOrders.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsMarketOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeLimitOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeMarketOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotLimitOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotMarketOrder.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgExternalTransfer.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgIncreasePositionMargin.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/exchange/msgs/MsgWithdraw.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/feegrant/msgs/MsgGrantAllowance.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/feegrant/msgs/MsgRevokeAllowance.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/gov/msgs/MsgDeposit.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/gov/msgs/MsgVote.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/insurance/msgs/MsgCreateInsuranceFund.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/insurance/msgs/MsgUnderwrite.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgCreateNamespace.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgDeleteNamespace.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgRevokeNamespaceRoles.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespace.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespaceRoles.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateParams.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/staking/msgs/MsgCancelUnbondingDelegation.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/staking/msgs/MsgDelegate.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/staking/msgs/MsgEditValidator.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/staking/msgs/MsgUndelegate.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgBurn.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgChangeAdmin.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgCreateDenom.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgMint.spec.ts
(1 hunks)packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgSetDenomMetadata.spec.ts
(1 hunks)packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts
(2 hunks)packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.spec.ts
(1 hunks)packages/sdk-ts/src/core/tx/eip712/eip712.spec.ts
(1 hunks)packages/sdk-ts/src/utils/address.ts
(1 hunks)packages/sdk-ts/src/utils/crypto.ts
(3 hunks)packages/sdk-ts/tsconfig.build.esm.json
(1 hunks)packages/sdk-ts/tsconfig.build.json
(1 hunks)packages/test-utils/CHANGELOG.md
(0 hunks)packages/test-utils/README.md
(0 hunks)packages/test-utils/package.json
(0 hunks)packages/test-utils/tsconfig.build.esm.json
(0 hunks)packages/test-utils/tsconfig.build.json
(0 hunks)packages/test-utils/tsconfig.json
(0 hunks)packages/ts-types/jest.config.js
(1 hunks)packages/ts-types/package.json
(2 hunks)packages/ts-types/tsconfig.build.esm.json
(1 hunks)packages/ts-types/tsconfig.build.json
(1 hunks)packages/utils/jest.config.js
(1 hunks)packages/utils/package.json
(3 hunks)packages/utils/src/classes/LocalStorage.ts
(1 hunks)packages/utils/src/helpers.ts
(2 hunks)packages/utils/src/test-utils/msgs.ts
(2 hunks)packages/utils/tsconfig.build.esm.json
(1 hunks)packages/utils/tsconfig.build.json
(1 hunks)packages/wallet-ts/.npmignore
(0 hunks)
⛔ Files not processed due to max files limit (57)
- packages/wallet-ts/LICENSE
- packages/wallet-ts/jest.config.js
- packages/wallets/wallet-base/package.json
- packages/wallets/wallet-base/src/types/enums.ts
- packages/wallets/wallet-base/src/types/provider.ts
- packages/wallets/wallet-base/src/types/strategy.ts
- packages/wallets/wallet-base/src/utils/wallet.ts
- packages/wallets/wallet-base/tsconfig.build.esm.json
- packages/wallets/wallet-base/tsconfig.build.json
- packages/wallets/wallet-core/package.json
- packages/wallets/wallet-core/src/broadcaster/MsgBroadcaster.ts
- packages/wallets/wallet-core/tsconfig.build.esm.json
- packages/wallets/wallet-core/tsconfig.build.json
- packages/wallets/wallet-cosmos-strategy/package.json
- packages/wallets/wallet-cosmos-strategy/tsconfig.build.esm.json
- packages/wallets/wallet-cosmos-strategy/tsconfig.build.json
- packages/wallets/wallet-cosmos/README.md
- packages/wallets/wallet-cosmos/package.json
- packages/wallets/wallet-cosmos/src/strategy/strategy.ts
- packages/wallets/wallet-cosmos/tsconfig.build.esm.json
- packages/wallets/wallet-cosmos/tsconfig.build.json
- packages/wallets/wallet-cosmostation/README.md
- packages/wallets/wallet-cosmostation/package.json
- packages/wallets/wallet-cosmostation/tsconfig.build.esm.json
- packages/wallets/wallet-cosmostation/tsconfig.build.json
- packages/wallets/wallet-evm/README.md
- packages/wallets/wallet-evm/package.json
- packages/wallets/wallet-evm/src/strategy/strategy.ts
- packages/wallets/wallet-evm/src/utils/index.ts
- packages/wallets/wallet-evm/tsconfig.build.esm.json
- packages/wallets/wallet-evm/tsconfig.build.json
- packages/wallets/wallet-ledger/README.md
- packages/wallets/wallet-ledger/package.json
- packages/wallets/wallet-ledger/src/strategy/Ledger/Base.ts
- packages/wallets/wallet-ledger/src/strategy/Ledger/hw/AccountManager.ts
- packages/wallets/wallet-ledger/src/strategy/Ledger/hw/index.ts
- packages/wallets/wallet-ledger/src/strategy/LedgerCosmos/hw/AccountManager.ts
- packages/wallets/wallet-ledger/src/strategy/LedgerCosmos/hw/index.ts
- packages/wallets/wallet-ledger/tsconfig.build.esm.json
- packages/wallets/wallet-ledger/tsconfig.build.json
- packages/wallets/wallet-magic/README.md
- packages/wallets/wallet-magic/package.json
- packages/wallets/wallet-magic/tsconfig.build.esm.json
- packages/wallets/wallet-magic/tsconfig.build.json
- packages/wallets/wallet-private-key/README.md
- packages/wallets/wallet-private-key/package.json
- packages/wallets/wallet-private-key/src/strategy/strategy.ts
- packages/wallets/wallet-private-key/tsconfig.build.esm.json
- packages/wallets/wallet-private-key/tsconfig.build.json
- packages/wallets/wallet-strategy/package.json
- packages/wallets/wallet-strategy/tsconfig.build.esm.json
- packages/wallets/wallet-strategy/tsconfig.build.json
- packages/wallets/wallet-trezor/README.md
- packages/wallets/wallet-trezor/package.json
- packages/wallets/wallet-trezor/src/strategy/hw/AccountManager.ts
- packages/wallets/wallet-trezor/src/strategy/hw/index.ts
- packages/wallets/wallet-trezor/src/strategy/strategy.ts
💤 Files with no reviewable changes (10)
- packages/wallet-ts/.npmignore
- packages/test-utils/README.md
- lerna.json
- packages/test-utils/CHANGELOG.md
- packages/test-utils/tsconfig.build.esm.json
- packages/test-utils/tsconfig.json
- packages/test-utils/package.json
- etc/replacements-ledger.js
- packages/test-utils/tsconfig.build.json
- etc/replacements.js
✅ Files skipped from review due to trivial changes (30)
- packages/sdk-ts/src/core/modules/authz/msgs/MsgGrantWithAuthorization.spec.ts
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotLimitOrder.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.spec.ts
- packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgBurn.spec.ts
- packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.spec.ts
- packages/sdk-ts/src/core/modules/feegrant/msgs/MsgRevokeAllowance.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.spec.ts
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelSpotOrders.spec.ts
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgRevokeNamespaceRoles.spec.ts
- packages/sdk-ts/src/core/tx/eip712/eip712.spec.ts
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgClaimVoucher.spec.ts
- packages/sdk-ts/src/core/modules/bank/msgs/MsgSend.spec.ts
- packages/sdk-ts/src/core/modules/insurance/msgs/MsgRequestRedemption.spec.ts
- packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.spec.ts
- packages/sdk-ts/src/core/modules/permissions/msgs/MsgCreateNamespace.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.spec.ts
- packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.spec.ts
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelSpotOrder.spec.ts
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsLimitOrder.spec.ts
- packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelDerivativeOrders.spec.ts
- packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMitoApi.spec.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.spec.ts
- packages/sdk-ts/src/core/modules/insurance/msgs/MsgUnderwrite.spec.ts
- packages/sdk-ts/src/core/tx/broadcaster/MsgBroadcasterWithPk.spec.ts
- deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ledger/Base.ts
- packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.spec.ts
- packages/utils/src/classes/LocalStorage.ts
- packages/sdk-ts/src/core/modules/feegrant/msgs/MsgGrantAllowance.spec.ts
🧰 Additional context used
🪛 GitHub Actions: Publish canary branch
packages/exceptions/package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/networks/package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/utils/package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/sdk-ts/package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/ts-types/package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
package.json
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
🔇 Additional comments (124)
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.spec.ts (1)
3-3
: LGTM: Import path updated as part of package deprecation.The import path change from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the PR objectives of deprecating packages.packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.spec.ts (1)
2-3
: LGTM! Import path updated correctly.The migration of
mockFactory
fromtest-utils
toutils/test-utils
aligns with the package deprecation objectives.packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.spec.ts (1)
1-1
: Verify consistent migration from test-utils package.The import change from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the package deprecation objective.Let's verify that all imports from the deprecated package have been updated:
✅ Verification successful
Import migration successfully verified
The migration from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
has been consistently implemented across all test files. While the old package remains in dependency files (package.json, yarn.lock), this is expected during the transition period.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining imports from the deprecated package rg "@injectivelabs/test-utils" # Search for the new import pattern to confirm consistent migration rg "@injectivelabs/utils/test-utils"Length of output: 13554
packages/sdk-ts/src/core/modules/authz/msgs/MsgExec.spec.ts (1)
2-2
: LGTM! Import path updated as part of package deprecation.The change aligns with the PR objectives of deprecating packages, moving test utilities from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
.packages/sdk-ts/src/core/modules/permissions/msgs/MsgDeleteNamespace.spec.ts (1)
3-3
: LGTM! Consistent import path update.The change follows the same pattern of moving test utilities to the new package location.
packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateParams.spec.ts (1)
3-3
: LGTM! Import path updated consistently.The change maintains consistency with other test files in updating the test utilities import path.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcOracleApi.ts (2)
3-4
: LGTM! Enhanced error handling imports.Added
grpcErrorCodeToErrorCode
for standardized error code conversion.
39-39
: LGTM! Improved error code handling.Updated to use
grpcErrorCodeToErrorCode
for consistent error code mapping across the SDK.packages/sdk-ts/src/client/chain/grpc/ChainGrpcTendermintApi.ts (2)
6-7
: LGTM! Standardized error code handling.The addition of
grpcErrorCodeToErrorCode
aligns with the refactoring goal of standardizing error handling across the SDK.
39-42
: LGTM! Improved error code transformation.The change from direct error code usage to
grpcErrorCodeToErrorCode(e.code)
ensures consistent error code handling across gRPC calls.packages/sdk-ts/src/client/chain/grpc/ChainGrpcPeggyApi.ts (2)
3-5
: LGTM! Consistent error handling imports.The import changes maintain consistency with other gRPC API classes in the codebase.
42-45
: LGTM! Standardized error transformation.The implementation of
grpcErrorCodeToErrorCode
matches the pattern used in other gRPC API classes.packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespaceRoles.spec.ts (1)
3-3
: LGTM! Updated import path for deprecated package.The change from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the PR objective of deprecating packages and consolidating utilities.packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawValidatorCommission.spec.ts (1)
2-2
: LGTM! Consistent import path update.The import path change maintains consistency with other spec files in moving away from the deprecated test-utils package.
packages/sdk-ts/src/core/modules/permissions/msgs/MsgUpdateNamespace.spec.ts (1)
3-3
: LGTM! Import path updated correctly.The change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' aligns with the package deprecation objectives.
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgChangeAdmin.spec.ts (1)
2-2
: LGTM! Import path updated consistently.The import path change maintains consistency with other files in the codebase.
packages/sdk-ts/src/core/modules/distribution/msgs/MsgWithdrawDelegatorReward.spec.ts (1)
2-2
: LGTM! Import path updated systematically.The import path change is consistent with the codebase-wide update pattern.
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgMint.spec.ts (1)
3-3
: LGTM! Import path updated as part of the package deprecation.The import path change aligns with the systematic update across the codebase.
Let's verify that all test files have been updated consistently:
✅ Verification successful
Import path migration verified successfully
All test files in the codebase are consistently using the new import path
@injectivelabs/utils/test-utils
, and no occurrences of the old import path@injectivelabs/test-utils
were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any remaining old import paths rg -l "@injectivelabs/test-utils" "packages/sdk-ts/src/**/*.spec.ts" # Verify new import paths are used consistently rg -l "@injectivelabs/utils/test-utils" "packages/sdk-ts/src/**/*.spec.ts"Length of output: 289
Script:
#!/bin/bash # Find all spec files first echo "=== Spec files ===" fd "\.spec\.ts$" packages/sdk-ts/src/ echo -e "\n=== Files with old import path ===" fd "\.spec\.ts$" packages/sdk-ts/src/ -x rg -l "@injectivelabs/test-utils" {} echo -e "\n=== Files with new import path ===" fd "\.spec\.ts$" packages/sdk-ts/src/ -x rg -l "@injectivelabs/utils/test-utils" {}Length of output: 11407
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.spec.ts (1)
3-3
: LGTM: Import path updated as part of package deprecation.The change aligns with the PR objective of deprecating the test-utils package.
packages/sdk-ts/src/core/modules/gov/msgs/MsgVote.spec.ts (1)
2-2
: LGTM: Import path updated consistently.The change maintains consistency with other test files in the refactoring effort.
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgCreateDenom.spec.ts (1)
2-2
: LGTM: Import path updated consistently.The change aligns with the package deprecation effort. Since this test relies heavily on mockFactory for multiple values, let's verify the functionality remains identical.
✅ Verification successful
Verified: mockFactory functionality remains identical after import path change
The mockFactory is consistently implemented in a single location and used uniformly across test files, maintaining the same mock values and functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify mockFactory exports and functionality remain identical # between old and new packages # Check if both packages export the same mock factory interface rg -A 5 "export.*mockFactory"Length of output: 431
Script:
#!/bin/bash # Get the full implementation of mockFactory and related mock values ast-grep --pattern 'export const mockFactory = { $$$ }' # Search for any other mockFactory exports or implementations rg -g '!*.{log,lock}' -A 10 'mockFactory' # Check the actual mock value declarations rg -g '!*.{log,lock}' '(ethereumAddress|injectiveAddress|validatorAddress) ='Length of output: 66865
packages/sdk-ts/src/core/modules/authz/msgs/MsgRevoke.spec.ts (1)
2-2
: LGTM: Import path updated consistently.The change maintains consistency with the package deprecation effort.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgDeposit.spec.ts (2)
Line range hint
1-24
: LGTM! Well-structured and comprehensive test implementation.The test suite thoroughly covers all necessary message formats (proto, amino, EIP-712, web3) and follows consistent patterns across files. The import path change doesn't affect the test logic.
Also applies to: 25-67
3-3
: Verify the new test-utils import path.The import path has been updated as part of deprecating the
test-utils
package. Let's verify the new location and implementation.✅ Verification successful
The test-utils import path is correctly implemented.
The import path
@injectivelabs/utils/test-utils
is properly mapped to its implementation inpackages/utils/src/test-utils/
and is being used consistently across all test files in the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the new test-utils implementation and check for potential breaking changes # Check if the new path exists fd -t f "test-utils" packages/sdk-ts/ # Check the implementation differences between old and new locations rg -A 5 "export.*mockFactory" packages/sdk-ts/Length of output: 86
Script:
#!/bin/bash # Broader search for test-utils and mockFactory rg -l "test-utils" . rg -l "mockFactory" . # Check contents of utils directory fd . packages/sdk-ts/src/utils -t f # Search for mockFactory usage rg "mockFactory" -A 3Length of output: 67266
Script:
#!/bin/bash # Check mockFactory implementation cat packages/utils/src/test-utils/mocks/index.ts # Verify no other test-utils implementations exist fd -t f "test-utils.ts" . fd -t f "test-utils.js" . # Check if there are any references to old paths rg "from ['\"]((?!@injectivelabs/utils/test-utils).)*test-utils['\"]"Length of output: 4148
Script:
#!/bin/bash # Search for test-utils imports with simpler pattern rg "from.*test-utils['\"]" . rg "require.*test-utils['\"]" .Length of output: 9280
packages/sdk-ts/src/core/modules/exchange/msgs/MsgWithdraw.spec.ts (1)
3-3
: Same change as in other files.The import path update follows the same pattern as other files.
packages/sdk-ts/src/core/modules/auction/msgs/MsgBid.spec.ts (1)
2-2
: Same change as in other files.The import path update follows the same pattern as other files.
packages/sdk-ts/src/core/modules/staking/msgs/MsgDelegate.spec.ts (1)
3-3
: Same change as in other files.The import path update follows the same pattern as other files.
packages/sdk-ts/src/core/modules/staking/msgs/MsgUndelegate.spec.ts (1)
3-3
: LGTM! Import path updated as part of test-utils deprecation.The change aligns with the PR objective of deprecating the standalone test-utils package.
Let's verify the consistency of this change across the codebase:
✅ Verification successful
Import path migration is consistent across the codebase
All spec files in the sdk-ts package consistently use the new import path
@injectivelabs/utils/test-utils
. While the package.json still lists the old package as a dependency, this might be intentional for backward compatibility or pending cleanup in a separate PR.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify no references to the old package remain rg "@injectivelabs/test-utils" # Verify all spec files use the new import path rg -t typescript "from '@injectivelabs/utils/test-utils'" "**/*.spec.ts"Length of output: 4555
Script:
#!/bin/bash # Search for old import pattern in spec files rg "from '@injectivelabs/test-utils'" "**/*.spec.ts" # Search for new import pattern in spec files rg "from '@injectivelabs/utils/test-utils'" "**/*.spec.ts" # Check package.json files for test-utils related entries fd "package.json" --exec grep -l "test-utils"Length of output: 338
Script:
#!/bin/bash # Search for old import pattern in sdk-ts spec files rg "from '@injectivelabs/test-utils'" packages/sdk-ts/src --type ts # Search for new import pattern in sdk-ts spec files rg "from '@injectivelabs/utils/test-utils'" packages/sdk-ts/src --type ts # Check content of relevant package.json files cat packages/utils/package.json | grep -A 5 -B 5 "test-utils" cat packages/sdk-ts/package.json | grep -A 5 -B 5 "test-utils"Length of output: 10698
packages/sdk-ts/src/core/modules/gov/msgs/MsgDeposit.spec.ts (1)
3-3
: LGTM! Import path updated consistently.The change maintains consistency with other spec files in the migration.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelDerivativeOrder.spec.ts (1)
2-2
: LGTM! Import path updated consistently.The change follows the established pattern of migrating from test-utils to utils/test-utils.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCancelBinaryOptionsOrder.spec.ts (1)
2-2
: LGTM! Import path updated consistently.The change maintains consistency with the test-utils deprecation effort.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmXApi.ts (1)
3-4
: LGTM! Error handling standardization.The addition of
grpcErrorCodeToErrorCode
improves error code consistency across the SDK.packages/sdk-ts/src/core/modules/staking/msgs/MsgBeginRedelegate.spec.ts (1)
3-3
: LGTM! Consistent with other test files.The import path change is part of the broader package deprecation effort.
packages/sdk-ts/src/core/modules/staking/msgs/MsgCancelUnbondingDelegation.spec.ts (1)
3-3
: LGTM! Consistent with other test files.The import path change is part of the broader package deprecation effort.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgIncreasePositionMargin.spec.ts (1)
2-2
: Verify the new test-utils package.The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is part of the package deprecation effort. Let's verify the availability and version of the new package location.
✅ Verification successful
Import path change is correct and properly implemented
The new import path
@injectivelabs/utils/test-utils
is consistently used across 60+ spec files in the sdk-ts package, confirming this is part of a coordinated package deprecation effort. The package is properly declared in the project's dependencies.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the new test-utils location exists and verify its exports fd --type f "test-utils" packages/utilsLength of output: 39
Script:
#!/bin/bash # Search for test-utils files across the repo fd --type f "test-utils" # Search for similar imports rg "@injectivelabs/utils/test-utils" # Check old location imports rg "@injectivelabs/test-utils"Length of output: 13579
packages/sdk-ts/src/core/modules/staking/msgs/MsgEditValidator.spec.ts (1)
2-2
: LGTM! Import path updated consistently.The import statement has been updated to use the new package location, maintaining consistency with other test files.
packages/sdk-ts/src/core/modules/exchange/msgs/MsgBatchCancelBinaryOptionsOrders.spec.ts (1)
2-2
: LGTM! Import path updated consistently.The import statement has been updated to use the new package location, maintaining consistency with other test files.
packages/sdk-ts/src/core/modules/insurance/msgs/MsgCreateInsuranceFund.spec.ts (1)
3-3
: LGTM! Import path updated consistently.The import statement has been updated to use the new package location, maintaining consistency with other test files.
packages/sdk-ts/src/core/modules/tokenfactory/msgs/MsgSetDenomMetadata.spec.ts (1)
2-2
: LGTM! Import path updated as part of package deprecation.The change from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the package deprecation objectives.packages/sdk-ts/src/client/chain/grpc/ChainGrpcIbcApi.ts (2)
3-4
: LGTM! Enhanced error handling with standardized error code conversion.Added
grpcErrorCodeToErrorCode
import for consistent error code handling across the SDK.
44-44
: Improved error handling with standardized error code conversion.The use of
grpcErrorCodeToErrorCode
ensures consistent error code handling across gRPC exceptions.Also applies to: 78-78
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcInsuranceFundApi.ts (2)
3-4
: LGTM! Enhanced error handling with standardized error code conversion.Added
grpcErrorCodeToErrorCode
import for consistent error code handling across the SDK.
60-60
: Improved error handling with standardized error code conversion.The use of
grpcErrorCodeToErrorCode
ensures consistent error code handling across gRPC exceptions.Also applies to: 88-88
packages/sdk-ts/src/core/modules/exchange/msgs/MsgInstantSpotMarketLaunch.spec.ts (2)
2-2
: LGTM! Import path updated as part of package deprecation.The change from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the package deprecation objectives.
Line range hint
28-28
: Address skipped test suite.The test suite is marked with TODO and skipped. Consider implementing the missing tests or document the reason for skipping.
Would you like me to help implement the missing tests or document the reason for skipping?
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcMetaApi.ts (1)
3-4
: LGTM! Consistent error handling implementation.The standardization of error handling using
grpcErrorCodeToErrorCode
across all methods improves code consistency and error reporting.Also applies to: 38-38, 64-64, 92-92
packages/sdk-ts/src/core/modules/authz/msgs/MsgGrant.spec.ts (1)
2-2
: LGTM! Successful migration from deprecated package.The import path update from
@injectivelabs/test-utils
to@injectivelabs/utils/test-utils
aligns with the PR objective of deprecating packages.packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcPortfolioApi.ts (1)
3-4
: LGTM! Standardized error handling implementation.The error handling has been properly standardized using
grpcErrorCodeToErrorCode
.Also applies to: 54-54, 95-95
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateSpotMarketOrder.spec.ts (1)
2-2
: LGTM! Import path updated as part of package deprecation.The change aligns with the PR objective of deprecating the
test-utils
package by moving themockFactory
utility to@injectivelabs/utils/test-utils
.Let's verify the new import path exists:
✅ Verification successful
Import path verified and correctly updated
The
mockFactory
utility is properly located atpackages/utils/src/test-utils
and the new import path@injectivelabs/utils/test-utils
is correctly used across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the new location of mockFactory fd -e ts -e js "mockFactory" packages/utils/test-utilsLength of output: 167
Script:
#!/bin/bash # First, find the utils package directory fd -t d "utils$" packages # Then, search for mockFactory in all TypeScript/JavaScript files rg -t ts -t js "mockFactory" packagesLength of output: 28138
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAuctionApi.ts (2)
3-4
: LGTM! Import added for standardized error handling.The addition of
grpcErrorCodeToErrorCode
aligns with the PR objective of standardizing error code processing.
48-48
: LGTM! Standardized error code handling implemented.Error handling has been updated to use
grpcErrorCodeToErrorCode
consistently across all methods, improving error code standardization.Let's verify this pattern is consistently applied across other gRPC API files:
Also applies to: 74-74, 101-101
✅ Verification successful
Standardized error handling verified across all gRPC APIs
The
grpcErrorCodeToErrorCode
implementation is consistently applied across all gRPC API files in the codebase, including Chain, Indexer, OLP, and Abacus APIs, confirming standardized error handling throughout the system.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for consistent usage of grpcErrorCodeToErrorCode in gRPC API files rg "grpcErrorCodeToErrorCode\(e\.code\)" packages/sdk-ts/src/client/Length of output: 22889
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuctionApi.ts (2)
3-4
: LGTM! Import added for standardized error handling.The addition of
grpcErrorCodeToErrorCode
aligns with the PR objective of standardizing error code processing.
43-43
: LGTM! Standardized error code handling implemented.Error handling has been updated to use
grpcErrorCodeToErrorCode
consistently across all methods, maintaining consistency with other gRPC API implementations.Also applies to: 73-73, 103-103
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeLimitOrder.spec.ts (1)
2-2
: LGTM! Import path updated as part of package deprecation.The change aligns with the PR objective of deprecating the
test-utils
package by moving themockFactory
utility to@injectivelabs/utils/test-utils
.packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateDerivativeMarketOrder.spec.ts (1)
2-2
: Verify package deprecation impact.The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' is part of the package deprecation effort.
✅ Verification successful
Import path change is properly implemented.
The functionality from @injectivelabs/test-utils has been successfully migrated to @injectivelabs/utils/test-utils with all necessary test utilities, mock data, and helper functions intact. The change is part of a planned package reorganization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if there are any remaining references to the old package rg "@injectivelabs/test-utils" # Check if there's a migration guide or breaking change notice fd "MIGRATION|BREAKING|CHANGELOG" -e mdLength of output: 5226
Script:
#!/bin/bash # Check if the new module exists fd "test-utils" packages/utils # Check for migration notes or breaking changes in relevant changelogs cat packages/utils/CHANGELOG.md cat packages/sdk-ts/CHANGELOG.mdLength of output: 65696
Script:
#!/bin/bash # Check content of test-utils directory ls -la packages/utils/src/test-utils/ cat packages/utils/src/test-utils/index.ts 2>/dev/null || trueLength of output: 424
Script:
#!/bin/bash # Check content of mocks and msgs ls -la packages/utils/src/test-utils/mocks/ cat packages/utils/src/test-utils/mocks/index.ts 2>/dev/null || true cat packages/utils/src/test-utils/msgs.ts 2>/dev/null || trueLength of output: 6487
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthApi.ts (1)
3-4
: LGTM! Improved error handling consistency.The use of
grpcErrorCodeToErrorCode
standardizes error code processing across gRPC APIs, which is a good practice for maintaining consistent error handling throughout the codebase.Also applies to: 44-44, 73-73, 105-105
packages/sdk-ts/src/client/chain/grpc/ChainGrpcMintApi.ts (1)
3-4
: LGTM! Consistent with error handling improvements.The changes follow the same pattern as in ChainGrpcAuthApi.ts, maintaining consistency in error handling across gRPC APIs.
Also applies to: 45-45, 76-76, 107-107
packages/sdk-ts/src/core/modules/exchange/msgs/MsgCreateBinaryOptionsMarketOrder.spec.ts (1)
2-2
: LGTM! Consistent with package deprecation changes.The import path update follows the same pattern as in MsgCreateDerivativeMarketOrder.spec.ts.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.spec.ts (1)
4-4
: Verify the new test-utils import path.The import path has been updated as part of deprecating the test-utils package. Let's verify that the new path is correctly configured.
✅ Verification successful
Import path for mockFactory is correctly configured
The mockFactory is properly exported from packages/utils/src/test-utils/mocks/index.ts and contains all the necessary mock data and utilities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify the new test-utils module exists and is exported correctly rg -g '*.{js,ts}' -l "export.*mockFactory" packages/utils/Length of output: 105
Script:
#!/bin/bash # Check the actual export configuration cat packages/utils/src/test-utils/mocks/index.tsLength of output: 3744
packages/sdk-ts/src/client/abacus/grpc/AbacusGrpcApi.ts (1)
4-4
: LGTM! Standardized error handling implementation.The addition of
grpcErrorCodeToErrorCode
improves error handling consistency across the codebase by standardizing how gRPC error codes are processed.Also applies to: 39-39, 75-75, 111-111
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTradingApi.ts (1)
3-4
: LGTM! Consistent error handling implementation.The standardized error handling has been correctly implemented across both methods, maintaining consistency with the rest of the codebase.
Also applies to: 39-39, 158-158
packages/sdk-ts/src/client/chain/grpc/ChainGrpcAuthZApi.ts (1)
3-3
: LGTM! Consistent error handling improvement.The standardization of error handling using
grpcErrorCodeToErrorCode
across all methods improves consistency and provides better error reporting.Also applies to: 70-70, 109-109, 148-148
packages/sdk-ts/src/client/chain/grpc/ChainGrpcTokenFactoryApi.ts (1)
3-4
: LGTM! Consistent error handling improvement.The standardization of error handling using
grpcErrorCodeToErrorCode
across all methods improves consistency and provides better error reporting.Also applies to: 45-45, 108-108, 138-138
packages/sdk-ts/src/client/chain/grpc/ChainGrpcInsuranceFundApi.ts (1)
3-4
: LGTM! Consistent error handling improvement.The standardization of error handling using
grpcErrorCodeToErrorCode
across all methods improves consistency and provides better error reporting.Also applies to: 43-43, 73-73, 105-105, 144-144, 183-183
packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.spec.ts (1)
3-3
: LGTM! Updated import path as part of package deprecation.The import path change from '@injectivelabs/test-utils' to '@injectivelabs/utils/test-utils' aligns with the package deprecation objective.
packages/sdk-ts/src/client/chain/grpc/ChainGrpcPermissionsApi.ts (1)
3-4
: LGTM! Consistent error handling implementation.The changes standardize error handling by using
grpcErrorCodeToErrorCode
across all methods, ensuring uniform error code processing throughout the API.Also applies to: 46-46, 83-83, 111-111, 138-138, 175-175, 205-205
packages/sdk-ts/src/client/chain/grpc/ChainGrpcDistributionApi.ts (1)
3-4
: LGTM! Consistent error handling with proper NoThrow variants.The changes standardize error handling while preserving special error cases in NoThrow variants, demonstrating a thoughtful implementation that balances consistency with specific requirements.
Also applies to: 43-43, 82-82, 128-128, 160-160, 196-196
packages/sdk-ts/src/client/chain/grpc/ChainGrpcGovApi.ts (1)
3-4
: LGTM! Consistent error handling across governance operations.The changes implement standardized error handling across all governance-related methods, ensuring uniform error code processing throughout the API.
Also applies to: 52-52, 93-93, 121-121, 161-161, 200-200, 228-228
packages/sdk-ts/src/core/tx/api/TxGrpcApi.ts (1)
7-10
: LGTM! Consistent error handling in transaction operations.The changes implement standardized error handling using
grpcErrorCodeToErrorCode
, aligning with the SDK-wide improvements.Also applies to: 80-80
packages/networks/src/endpoints.ts (1)
49-49
: LGTM! Consistent endpoint updates across network configurations.The changes correctly update the explorer endpoints to use the dedicated explorer subdomain, maintaining consistency across different network environments.
Also applies to: 116-116, 146-146, 176-176
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcCampaignApi.ts (1)
3-3
: LGTM! Standardized error handling with grpcErrorCodeToErrorCode.The changes consistently apply the error code transformation across all methods, improving error handling standardization.
Also applies to: 75-75, 134-134, 186-186, 234-234, 272-272, 331-331
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcAccountApi.ts (1)
4-4
: LGTM! Consistent error handling improvements.The changes properly implement the standardized error code transformation across all methods, maintaining consistency with other API modules.
Also applies to: 60-60, 89-89, 120-120, 149-149, 212-212, 257-257, 291-291
packages/sdk-ts/src/client/chain/grpc/ChainGrpcBankApi.ts (1)
3-4
: LGTM! Standardized error handling in chain API.The changes successfully implement the consistent error code transformation pattern across all bank API methods, aligning with the broader refactoring effort.
Also applies to: 49-49, 85-85, 120-120, 152-152, 188-188, 222-222, 251-251, 288-288
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcArchiverApi.ts (1)
3-3
: Standardized error code handling improves consistency.The introduction of
grpcErrorCodeToErrorCode
and its consistent application across all error handling blocks enhances error code standardization. This change ensures uniform error code translation across the entire module.Let's verify the error code mapping implementation:
Also applies to: 50-50, 87-87, 124-124, 174-174, 224-224, 272-272, 320-320, 367-367
✅ Verification successful
Error code standardization verified across all GRPC APIs
The
grpcErrorCodeToErrorCode
implementation ensures consistent error code translation throughout the codebase, with uniform usage across all GRPC API error handling blocks.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the grpcErrorCodeToErrorCode implementation # and its usage across the codebase # Check the implementation rg -A 5 "export const grpcErrorCodeToErrorCode" --type ts # Verify consistent usage rg "grpcErrorCodeToErrorCode\(.*\.code\)" --type tsLength of output: 23472
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcTransactionApi.ts (1)
103-103
: Consistent error handling in deprecated class.While the class is deprecated, the error handling improvements maintain consistency with the rest of the codebase. This is good practice during the deprecation period.
Also applies to: 179-179, 248-248, 304-304, 328-328
packages/sdk-ts/src/client/chain/grpc/ChainGrpcWasmApi.ts (1)
3-4
: Standardized error handling in WASM operations.The implementation of
grpcErrorCodeToErrorCode
across all WASM-related operations ensures consistent error handling. This standardization improves error reporting reliability across contract interactions.Also applies to: 59-59, 102-102, 139-139, 170-170, 209-209, 242-242, 276-276, 306-306, 346-346
packages/sdk-ts/src/client/olp/grpc/OLPGrpcApi.ts (1)
2-4
: Standardized error handling with preserved module context.The implementation maintains module-specific error context while standardizing error code handling through
grpcErrorCodeToErrorCode
. This approach ensures consistent error handling while preserving important module-specific information.Also applies to: 40-40, 69-69, 110-110, 148-148, 192-192, 233-233, 280-280, 327-327, 363-363, 406-406
packages/sdk-ts/src/client/chain/grpc/ChainGrpcExchangeApi.ts (1)
3-4
: Consistent error handling implementation looks good!The standardization of error code handling using
grpcErrorCodeToErrorCode
across all methods improves error reporting consistency and maintainability.Also applies to: 43-43, 71-71, 101-101, 134-134, 164-164, 194-194, 231-231, 258-258, 288-288, 320-320, 352-352
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcExplorerApi.ts (1)
3-4
: Error handling standardization looks good!The consistent use of
grpcErrorCodeToErrorCode
across all methods improves error reporting reliability.Also applies to: 39-39, 114-114, 145-145, 176-176, 231-231, 286-286, 344-344, 372-372, 452-452, 531-531, 559-559
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcSpotApi.ts (1)
3-4
: Error handling standardization looks good!The consistent use of
grpcErrorCodeToErrorCode
across all methods enhances error reporting reliability.Also applies to: 70-70, 99-99, 185-185, 293-293, 410-410, 461-461, 525-525, 563-563, 594-594, 649-649
packages/sdk-ts/src/client/chain/grpc/ChainGrpcStakingApi.ts (1)
3-4
: Error handling standardization and NoThrow variants look good!The consistent use of
grpcErrorCodeToErrorCode
across all methods and proper handling of "does not exist" cases in NoThrow variants improve error handling reliability.Also applies to: 44-44, 71-71, 106-106, 135-135, 179-179, 227-227, 271-271, 319-319, 357-357, 401-401, 449-449, 493-493, 541-541, 585-585, 633-633, 676-676, 723-723
packages/exceptions/src/exceptions/types/codes.ts (1)
3-21
: LGTM! Well-structured gRPC error code enumeration.The enum provides a comprehensive set of standard gRPC error codes with clear, descriptive names.
packages/sdk-ts/src/client/indexer/grpc/IndexerGrpcDerivativesApi.ts (1)
Line range hint
1-964
: Apply the same error handling utility pattern here.Similar to IndexerGrpcMitoApi.ts, consider extracting the repeated error handling pattern into a utility function.
packages/utils/tsconfig.build.json (1)
6-7
: LGTM! Proper configuration for CommonJS build.The configuration correctly sets up CommonJS module compilation with appropriate module resolution strategy. This aligns with the dual CJS/ESM build approach.
Also applies to: 10-11
packages/utils/tsconfig.build.esm.json (1)
4-4
: Verify package.json configuration for NodeNext compatibility.The switch to NodeNext module system is good for modern Node.js compatibility. However, this requires proper configuration in package.json to support dual CJS/ESM builds.
Run this script to verify the package.json configuration:
Also applies to: 10-10
✅ Verification successful
✓ Package.json exports field is correctly configured for NodeNext
The package.json has proper conditional exports supporting both ESM and CommonJS, with correct type definitions and module paths. The configuration aligns well with the NodeNext module system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if package.json is properly configured for dual CJS/ESM builds # Expected: Should find "exports" field with proper conditional exports # Check package.json in utils package echo "Checking packages/utils/package.json:" jq '.exports' packages/utils/package.json # Verify import/require conditions jq '.exports | select(. != null) | .. | .import? // .require?' packages/utils/package.jsonLength of output: 1621
packages/sdk-ts/tsconfig.build.esm.json (1)
4-4
: Verify dependencies compatibility with NodeNext.The NodeNext configuration is consistent with other packages. However, as this is the main SDK package, we should verify that all dependencies support ESM imports.
Also applies to: 10-10
✅ Verification successful
Dependencies are compatible with NodeNext module resolution
The key dependencies in the SDK package demonstrate proper ESM support through exports fields or known ESM compatibility. The @InjectiveLabs ecosystem packages and core blockchain libraries all support dual CJS/ESM builds, making them fully compatible with NodeNext module resolution.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if dependencies in package.json support ESM # Expected: Dependencies should have "exports" field or "type": "module" # Get all dependencies echo "Checking ESM support in dependencies:" jq '.dependencies' packages/sdk-ts/package.json | jq -r 'keys[]' | while read pkg; do if [ ! -z "$pkg" ]; then echo "Checking $pkg:" npm view $pkg exports --json 2>/dev/null || echo "No exports field" fi doneLength of output: 15027
packages/networks/tsconfig.build.json (1)
5-6
: LGTM! Consistent with other packages.The CommonJS build configuration maintains consistency with other packages in the monorepo.
Also applies to: 10-11
packages/ts-types/tsconfig.build.json (1)
6-7
: LGTM! Proper setup for type definitions.The CommonJS configuration is consistent with other packages and appropriate for generating type definitions.
Also applies to: 10-11
packages/sdk-ts/tsconfig.build.json (1)
5-6
: LGTM! Appropriate module configuration for CommonJS build.The addition of
"module": "commonjs"
and"moduleResolution": "node"
is correct for the CommonJS build configuration.packages/ts-types/tsconfig.build.esm.json (1)
4-4
: LGTM! Verify package.json type field alignment.The transition to
"NodeNext"
for both module and moduleResolution is appropriate for modern Node.js environments.Please ensure this aligns with the package.json configuration:
Also applies to: 10-10
✅ Verification successful
Configuration alignment verified ✓
The package.json
"type": "module"
field correctly aligns with the tsconfig's"module": "NodeNext"
setting for ESM output.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if package.json has the correct type field for ESM jq -r '.type // empty' packages/ts-types/package.jsonLength of output: 62
packages/exceptions/tsconfig.build.json (1)
5-6
: LGTM! Consistent with other packages.The CommonJS module configuration matches the pattern established in other packages.
packages/exceptions/tsconfig.build.esm.json (1)
4-4
: LGTM! Verify package.json type field alignment.The NodeNext configuration is appropriate and consistent with other packages.
Please ensure this aligns with the package.json configuration:
Also applies to: 10-10
✅ Verification successful
Configuration verified: package.json and tsconfig.build.esm.json are properly aligned for ESM
The package.json
"type": "module"
field correctly aligns with the"module": "NodeNext"
TypeScript configuration for ES modules support.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if package.json has the correct type field for ESM jq -r '.type // empty' packages/exceptions/package.jsonLength of output: 64
packages/networks/tsconfig.build.esm.json (1)
4-4
: LGTM! Verify package.json type field alignment.The NodeNext configuration is appropriate and consistent with other packages.
Please ensure this aligns with the package.json configuration:
Also applies to: 10-10
✅ Verification successful
Configuration verified: package.json and tsconfig.build.esm.json are correctly aligned
The package.json "type": "module" field is properly set for ESM output, matching the NodeNext module configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if package.json has the correct type field for ESM jq -r '.type // empty' packages/networks/package.jsonLength of output: 62
packages/ts-types/jest.config.js (1)
Line range hint
1-9
: Verify ESM configuration compatibility.The migration to ESM looks good, but let's ensure all dependencies are ESM-compatible.
Run this script to verify the configuration:
✅ Verification successful
ESM configuration is properly set up ✅
The configuration is correctly set up for ESM:
- Root Jest config uses ESM presets and transforms
- TypeScript ESM config exists with proper module settings
- Base config import path is correct
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if base config and referenced TypeScript config exist and are ESM compatible echo "Checking base Jest config..." cat ../../jest.config.js echo -e "\nChecking TypeScript ESM config..." cat tsconfig.build.esm.json echo -e "\nChecking package.json for type:module..." cat package.json | jq '.type'Length of output: 447
Script:
#!/bin/bash # Search for Jest and TypeScript config files echo "Searching for Jest config files..." fd -e js -e cjs -e mjs "jest.config" echo -e "\nSearching for TypeScript config files..." fd "tsconfig" echo -e "\nChecking current directory structure..." pwd && ls -laLength of output: 5943
Script:
#!/bin/bash echo "Checking root Jest config..." cat jest.config.js echo -e "\nChecking ts-types TypeScript ESM config..." cat packages/ts-types/tsconfig.build.esm.json echo -e "\nChecking ts-types package.json..." cat packages/ts-types/package.json | jq '{type,module,exports,main}'Length of output: 7703
packages/sdk-ts/jest.config.js (1)
Line range hint
1-9
: Same ESM migration pattern as ts-types package.The changes are identical to those in packages/ts-types/jest.config.js.
packages/networks/jest.config.js (1)
Line range hint
1-9
: Same ESM migration pattern as other packages.The changes are identical to those in other Jest config files.
packages/utils/src/test-utils/msgs.ts (3)
1-2
: Verify all BigNumber imports are consistently updated.The change from external BigNumber to local BigNumberInBase is good, but let's ensure consistency across the codebase.
✅ Verification successful
BigNumber import change is consistent with codebase patterns
The change to use local BigNumberInBase import in
msgs.ts
follows the established pattern within the utils package, where implementation files use local imports from the classes directory.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any remaining BigNumber imports from @injectivelabs/utils echo "Checking for old BigNumber imports..." rg "import.*BigNumber.*from.*@injectivelabs/utils" echo -e "\nChecking for new BigNumberInBase usage..." rg "import.*BigNumberInBase.*from"Length of output: 7351
75-78
: Verify BigNumberInBase calculation equivalence.The amount calculation using BigNumberInBase should produce the same results as the previous BigNumber implementation.
✅ Verification successful
BigNumberInBase calculation verified as correct
The gas amount calculation using
BigNumberInBase
follows the established pattern used throughout the codebase for gas fee calculations and maintains numerical precision as expected.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for similar calculations in tests or documentation rg "BigNumber.*times.*DEFAULT_GAS_PRICE" -A 2Length of output: 47
Script:
#!/bin/bash # Search for BigNumberInBase usage patterns ast-grep --pattern 'new BigNumberInBase($$$)' # Search for gas calculation tests rg -t ts "describe.*gas" -A 5 # Search for BigNumber usage (both types) rg "BigNumber(InBase)?" -A 2Length of output: 66499
Line range hint
1-99
: Consider deprecation impact of test-utils package.According to the PR title, test-utils is being deprecated. This file might need to be moved or removed.
packages/utils/src/helpers.ts (1)
80-82
: LGTM! Consistent use of BigNumberInBase.The transition to BigNumberInBase for gas calculations improves consistency in number handling across the codebase.
Also applies to: 115-116, 122-124, 127-127
packages/sdk-ts/src/core/accounts/PrivateKey.spec.ts (2)
2-2
: LGTM! ESM-compliant import path.The .js extension in the import path aligns with ESM requirements.
131-141
: LGTM! Improved signature verification test.The test now explicitly verifies signatures from both ethers and private key implementations, providing better coverage and clarity.
jest.config.js (2)
185-188
: LGTM! Necessary configuration for ESM module.The transformIgnorePatterns configuration correctly allows transformation of the @noble/secp256k1 ESM module.
90-90
: Verify if the crypto-es mapping is needed.The commented mapping suggests uncertainty. Please verify if this mapping is required for the tests to pass.
✅ Verification successful
The crypto-es mapping can be safely removed
The codebase has been updated to use crypto-js directly instead of crypto-es, as evidenced by the imports in
packages/sdk-ts/src/utils/crypto.ts
. The commented mapping in jest.config.js is no longer needed and can be removed.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if crypto-es is imported anywhere in the codebase rg "from ['\"](crypto-es|crypto-js)['\"]" -t tsLength of output: 194
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Ninji.ts (1)
245-245
: Consider updating implementation to match new type signature.The callback type now supports
string[]
but the implementation only passes a single account. Consider updating the implementation to potentially handle multiple accounts if that's the intended use case.deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Leap.ts (1)
247-247
: Implementation looks good!The type signature update is consistent with other wallet strategies while maintaining the correct implementation for Leap wallet's single-account model.
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Keplr.ts (1)
247-247
: Implementation looks good!The type signature update is consistent with other wallet strategies while maintaining the correct implementation for Keplr wallet's single-account model.
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/BitGet/index.ts (1)
67-67
: LGTM! Type safety improvements look good.The changes enhance type safety through explicit type assertions and broaden the callback parameter type to handle both single and multiple account changes.
Also applies to: 96-96, 152-152, 207-207, 221-221, 239-239, 278-278
deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Metamask/index.ts (2)
242-242
: Add maximum retry attempts to prevent infinite recursion.Similar to TrustWallet, the
transactionReceiptRetry
function needs a maximum retry limit to prevent infinite recursion.
224-224
: Fix incorrect Promise type assertion.The type assertion
as Promise<string>
is incorrect asethereum.request
already returns a Promise.deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Okx/index.ts (2)
239-242
: Add maximum retry attempts to prevent infinite recursion.The
transactionReceiptRetry
function needs a maximum retry limit to prevent infinite recursion.
224-224
: Fix incorrect Promise type assertion.The type assertion
as Promise<string>
is incorrect asethereum.request
already returns a Promise.deprecated/packages/wallet-ts/src/strategies/wallet-strategy/strategies/Phantom/index.ts (3)
26-29
: LGTM! Class declaration formatting improves readability.The multi-line class declaration with separate lines for extends and implements improves code readability.
70-72
: Type assertions enhance type safety.The explicit type assertions for method return types improve type safety and make the code more maintainable.
Also applies to: 98-101, 154-157, 212-212, 226-226, 241-244
283-283
: Verify the impact of the callback type change.The callback type has been updated to accept either
AccountAddress
orstring[]
. While this provides more flexibility, ensure that consumers of this API are prepared to handle both types.✅ Verification successful
Callback type change has been properly propagated across the codebase
The callback type change has been consistently implemented across all active wallet strategies. The only exceptions are in deprecated packages which are no longer maintained.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of onAccountChange to verify consumers can handle the new type rg -A 3 "onAccountChange\(" --type tsLength of output: 8111
packages/ts-types/package.json (3)
7-7
: LGTM! ESM migration.The addition of
"type": "module"
aligns with the migration to ECMAScript modules.🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
58-60
: LGTM! Correct dependency categorization.Moving
shx
to devDependencies is appropriate as it's only used during development/build.🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
Line range hint
1-63
: Address pipeline warnings.The build pipeline reports missing peer dependencies:
- Missing
@babel/core
- Incorrect peer dependency for
typedoc-monorepo-link-types
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/exceptions/package.json (1)
7-7
: LGTM! Consistent ESM migration.The addition of
"type": "module"
is consistent with the ESM migration across packages.🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/networks/package.json (1)
6-6
: Verify ESM transition impact on existing consumers.While adding
"type": "module"
aligns with the ESM transition, ensure that CommonJS consumers are not affected. The dual export configuration looks correct, but consider:
- Testing the package in both ESM and CommonJS environments
- Documenting the change in the changelog
- Potentially bumping the major version if this is a breaking change
✅ Verification successful
ESM transition is properly configured and safe ✅
The package maintains full CommonJS compatibility through:
- Dual CJS/ESM builds with correct configuration
- Proper exports field routing
- Format-specific package.json stubs in dist directories
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for direct CommonJS require statements that might break rg "require\(['\"]@injectivelabs/networks['\"]" -A 5Length of output: 58
Script:
#!/bin/bash # Check package.json exports configuration cat packages/networks/package.json # Look for .cjs files that might be affected fd '\.cjs$' packages/networks/ # Check for any require statements within the package rg "require\(" packages/networks/Length of output: 2388
Script:
#!/bin/bash # Check tsconfig files to verify dual-format build setup cat packages/networks/tsconfig.build.json cat packages/networks/tsconfig.build.esm.json # Check package.json stubs that are copied during build cat etc/stub/package.json.stub cat etc/stub/package.esm.json.stubLength of output: 899
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/utils/package.json (2)
84-87
: Good: Improved dependency organization.Moving
shx
to devDependencies is correct as it's only used in build scripts. The update ofstore2
to^2.14.3
is also good for security and bug fixes.🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
39-57
: Clarify the status of test-utils package.The addition of test-utils export paths seems to contradict the PR objective of "deprecating packages". Please clarify if test-utils is being:
- Deprecated but temporarily maintained for backward compatibility
- Moved into the utils package instead of being deprecated
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
packages/sdk-ts/package.json (2)
139-140
: Verify crypto operations after noble packages update.The updates to
@noble/curves
and addition of@noble/hashes
might affect cryptographic operations. Please ensure:
- All crypto operations are tested with the new versions
- Performance impact is evaluated
- Security implications are reviewed
✅ Verification successful
Noble packages update appears safe
The codebase uses only stable APIs from
@noble/curves
(secp256k1) for basic key operations. The new@noble/hashes
dependency isn't directly used in the crypto implementation. The update should be safe as:
- Only uses stable secp256k1 methods (getPublicKey, ProjectivePoint)
- Core crypto operations rely on crypto-js instead
- No breaking changes detected in used functionality
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Find files using noble packages rg "@noble/(curves|hashes)" -lLength of output: 621
Script:
#!/bin/bash # Check crypto.ts implementation cat packages/sdk-ts/src/utils/crypto.ts # Check git history for previous versions git show HEAD:packages/sdk-ts/package.json | grep "@noble/"Length of output: 3109
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
11-11
: Verify ESM exports configuration.The addition of
"type": "module"
with the complex exports configuration needs verification. Please:
- Test importing the package in different environments (Node.js, bundlers)
- Verify all export paths resolve correctly
- Consider adding integration tests for package resolution
✅ Verification successful
ESM/CJS dual format configuration is correct ✅
The package.json has a well-structured exports field with proper conditional exports for all environments (ESM, CJS, React Native) and correct type definitions. The build setup correctly handles dual-format output with separate tsconfig files and post-build steps. The missing files are expected as they are build artifacts.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if all exported paths exist for path in $(rg '"import"|"require"' packages/sdk-ts/package.json | rg -o '"\./[^"]+\.js"' | tr -d '"'); do if [ ! -f "packages/sdk-ts/$path" ]; then echo "Missing file: $path" fi doneLength of output: 2074
Script:
#!/bin/bash # Check package.json exports and build configuration echo "=== Package.json contents ===" cat packages/sdk-ts/package.json echo -e "\n=== TypeScript configs ===" fd tsconfig.json packages/sdk-ts/Length of output: 5987
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
import EthereumApp from '@ledgerhq/hw-app-eth' | ||
import Transport from '@ledgerhq/hw-transport' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Remove redundant imports of @ledgerhq/hw-app-eth
.
The code has both static and dynamic imports of the same module:
- Static:
import EthereumApp from '@ledgerhq/hw-app-eth'
- Dynamic:
const EthereumApp = await import('@ledgerhq/hw-app-eth')
This is redundant and could cause confusion.
Choose one approach:
-import EthereumApp from '@ledgerhq/hw-app-eth'
And update the getInstance
method to use the dynamic import consistently:
async getInstance(): Promise<EthereumApp> {
if (!this.ledger) {
const transport = await LedgerTransport.getTransport()
const { default: EthereumApp } = await import('@ledgerhq/hw-app-eth')
this.ledger = new EthereumApp(transport)
// ...
}
return this.ledger
}
import { ChainInfo } from './types.js' | ||
|
||
const INJ_DENOM = 'inj' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Migration of INJ_DENOM constant appears incomplete
The constant is now duplicated across the codebase:
- Defined in packages/utils/src/constants.ts
- Newly added in packages/networks/src/chainInfos.ts
- Still imported from @injectivelabs/utils in multiple test files under packages/sdk-ts/
If the goal is to deprecate @injectivelabs/utils, the constant should be fully migrated to the new location and all imports should be updated accordingly.
🔗 Analysis chain
LGTM! Moving INJ_DENOM locally aligns with package deprecation goals.
The change reduces external dependencies by moving the constant locally, which is consistent with the PR's refactoring objectives.
Let's verify there are no inconsistencies in the INJ_DENOM value across the codebase:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other declarations or usages of INJ_DENOM
# to ensure consistency across the codebase
rg -g '!*.{json,md}' "INJ_DENOM.*=.*['\"]inj['\"]" -A 1
Length of output: 293
Script:
#!/bin/bash
# Search for imports of INJ_DENOM from utils package
rg "import.*\{.*INJ_DENOM.*\}.*from.*@injectivelabs/utils" -A 1
# Also check for any other files still using the utils constant
ast-grep --pattern 'from "@injectivelabs/utils"'
Length of output: 1088
@@ -1,6 +1,6 @@ | |||
import { BigNumberInBase } from '@injectivelabs/utils' | |||
import MsgExternalTransfer from './MsgExternalTransfer.js' | |||
import { mockFactory } from '@injectivelabs/test-utils' | |||
import { mockFactory } from '@injectivelabs/utils/test-utils' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Package Cleanup Required: test-utils Migration
The code migration is complete with all files using the new import path, but the old package remains as a dependency:
- Remove
@injectivelabs/test-utils
frompackages/sdk-ts/package.json
- Update yarn.lock files after dependency removal
🔗 Analysis chain
LGTM! Verify test-utils package deprecation.
The import path change aligns with the package deprecation strategy.
Let's verify that the old package is being fully deprecated:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any remaining references to the old package
rg -l "@injectivelabs/test-utils"
# Check if the new path is consistently used
rg -l "@injectivelabs/utils/test-utils"
Length of output: 5517
Script:
#!/bin/bash
# Check package.json content
cat packages/sdk-ts/package.json | grep -A 5 -B 5 "test-utils"
# Look for actual imports of old package
rg "from ['\"]\@injectivelabs\/test-utils['\"]"
rg "require\(['\"]\@injectivelabs\/test-utils['\"]"
Length of output: 919
Script:
#!/bin/bash
# Search for imports of the old package with fixed regex
rg "@injectivelabs/test-utils" -t ts -t js --type-add 'ts:*.{ts,tsx}' --type-add 'js:*.{js,jsx}' -g '!*.lock' -g '!package.json'
Length of output: 128
TransactionException, | ||
grpcErrorCodeToErrorCode, | ||
GrpcUnaryRequestException, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider removing deprecated class.
The class is marked as deprecated in favor of IndexerGrpcWeb3GwApi
. Consider removing this class in a future major version update to reduce maintenance overhead and prevent usage of deprecated APIs.
return (await ethereum.request({ | ||
method: 'eth_signTypedData_v4', | ||
params: [eip712json, address], | ||
}) | ||
})) as Promise<string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix incorrect Promise type assertion.
The type assertion as Promise<string>
is incorrect as ethereum.request
already returns a Promise. The result should be asserted as string
.
- })) as Promise<string>
+ })) as string
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
return (await ethereum.request({ | |
method: 'eth_signTypedData_v4', | |
params: [eip712json, address], | |
}) | |
})) as Promise<string> | |
return (await ethereum.request({ | |
method: 'eth_signTypedData_v4', | |
params: [eip712json, address], | |
})) as string |
const receipt = (await ethereum.request({ | ||
method: 'eth_getTransactionReceipt', | ||
params: [txHash], | ||
}) | ||
})) as string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add maximum retry attempts to prevent infinite recursion.
The transactionReceiptRetry
function could potentially enter an infinite recursion if the receipt is consistently unavailable. This could lead to a stack overflow.
Add a maximum retry limit:
const interval = 1000
+ const maxRetries = 10
+ let attempts = 0
const transactionReceiptRetry = async () => {
const receipt = (await ethereum.request({
method: 'eth_getTransactionReceipt',
params: [txHash],
})) as string
if (!receipt) {
+ if (attempts >= maxRetries) {
+ throw new Error('Maximum retry attempts reached')
+ }
+ attempts++
await sleep(interval)
await transactionReceiptRetry()
}
return receipt
}
Committable suggestion skipped: line range outside the PR's diff.
@@ -278,7 +278,7 @@ export default class WalletConnect | |||
} | |||
|
|||
async onAccountChange( | |||
callback: (account: AccountAddress) => void, | |||
callback: (account: AccountAddress | string[]) => void, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Resolve type inconsistency in callback usage.
While the callback type suggests it can receive either AccountAddress | string[]
, the implementation always passes a single account (accounts[0]
). This could lead to confusion for consumers expecting to receive the full array.
Consider either:
- Updating the implementation to pass the full array:
-wc.on('accountsChanged', (accounts) => callback(accounts[0]))
+wc.on('accountsChanged', (accounts) => callback(accounts))
- Or keeping the type specific to what's actually passed:
-callback: (account: AccountAddress | string[]) => void,
+callback: (account: AccountAddress) => void,
Committable suggestion skipped: line range outside the PR's diff.
"@types/jest": "^29.5.14", | ||
"@types/node": "^22.10.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Address peer dependency warnings.
The pipeline shows warnings about missing peer dependencies:
@babel/core
is missingtypedoc-monorepo-link-types
requires[email protected]
Consider:
- Adding
@babel/core
as a dev dependency - Updating
typedoc
to match the required version or updatingtypedoc-monorepo-link-types
Also applies to: 93-96, 100-100, 112-112
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
@@ -14,7 +14,7 @@ | |||
}, | |||
"scripts": { | |||
"postinstall": "node etc/bootstrapEnv", | |||
"build": "node etc/bootstrapEnv && lerna run build", | |||
"build": "node etc/bootstrapEnv && patch-package && lerna run build", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Document the purpose and status of 8 wallet-related patches
Found 8 undocumented patches for wallet connectivity dependencies:
- 5 Ledger hardware wallet patches (@ledgerhq/*)
- 1 Trezor connection patch (@trezor/connect-web)
- 1 WalletConnect provider patch
- 1 store2 utility patch
Please document:
- The purpose of each patch and why it's needed
- Whether these are temporary workarounds or permanent solutions
- If there are related upstream issues that need to be tracked
🔗 Analysis chain
Document patch-package usage.
The addition of patch-package
to build and bootstrap scripts indicates custom patches are being applied. Please:
- Document the patches in the PR description
- Add a README section explaining which packages are patched and why
- Consider if these patches are temporary or need upstream fixes
Also applies to: 38-38
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing patches
fd -t f . patches/
Length of output: 375
Script:
#!/bin/bash
# Check README files and documentation
echo "=== Searching for patch documentation in README files ==="
fd -t f -e md . | xargs rg -i "patch" -C2
echo -e "\n=== Checking PR description if available ==="
gh pr view --json body | jq -r .body
Length of output: 361
🧰 Tools
🪛 GitHub Actions: Publish canary branch
[warning] Missing peer dependency '@babel/core' for multiple packages
[warning] Incorrect peer dependency for typedoc-monorepo-link-types, requires [email protected]
0ccb2da
to
43cd4c0
Compare
43cd4c0
to
c17bf9f
Compare
Report too large to display inline |
- @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected]
- @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected] - @injectivelabs/[email protected]
Summary by CodeRabbit
I'll craft concise release notes highlighting the key changes and improvements across the project.
Release Notes
Module System Transition
Error Handling Improvements
Cryptography Enhancements
Dependency Updates
Test Utilities
Performance Optimizations
These release notes provide a high-level overview of the significant changes while maintaining confidentiality about specific implementation details.