feat: query contracts command #392
Conversation
📝 WalkthroughWalkthroughThis change introduces a new CLI command group for querying contract registry data, including commands to list and show contract addresses by chain ID and type. Supporting utilities for address parsing and formatting are added, as well as Zod schemas for command option validation. Dependencies and constants are updated to support the new functionality. Additionally, Node.js versions in GitHub Actions workflows are updated from 21 to 22. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant ContractsRegistry (via ethers.js)
participant Utils
User->>CLI: Run "contracts list" or "contracts show" command
CLI->>ContractsRegistry: fetchContracts(rpcUrl)
ContractsRegistry-->>CLI: List of contracts
CLI->>Utils: formatAddress(address)
Utils-->>CLI: Formatted address
CLI-->>User: Output (JSON or table for list, address for show)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~40 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
packages/commands/src/query/contracts/show.ts (2)
13-17: Consider making the interface more type-safe.The
ContractDatainterface duplicates what might already be defined elsewhere. Consider importing this from a shared types file to maintain consistency and avoid duplication.#!/bin/bash # Description: Check if ContractData interface is defined elsewhere in the codebase ast-grep --pattern 'interface ContractData { $$$ }'
61-63: Improve error handling specificity.The generic error catch could be more specific. Consider handling different error types (network errors, contract errors, parsing errors) differently to provide more targeted user feedback.
} catch (error) { - console.error(chalk.red("Error details:"), error); + if (error instanceof Error) { + if (error.message.includes('network')) { + console.error(chalk.red("Network error: Please check your RPC URL")); + } else if (error.message.includes('contract')) { + console.error(chalk.red("Contract error: Unable to fetch contract data")); + } else { + console.error(chalk.red("Error:"), error.message); + } + } else { + console.error(chalk.red("Unknown error occurred")); + } + process.exit(1); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (62)
typechain-types/@zetachain/protocol-contracts/contracts/Revert.sol/Revertable.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorBase.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorNative.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorNonNative.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistry.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistryErrors.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistryEvents.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/helpers/interfaces/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/GatewayZEVM.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/ICoreRegistry.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/IGatewayZEVM.sol/IGatewayZEVM.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/IZRC20.sol/IZRC20.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/IZRC20.sol/IZRC20Metadata.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/UniversalContract.sol/UniversalContract.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/interfaces/index.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/libraries/GatewayZEVMValidations.tsis excluded by!typechain-types/**typechain-types/@zetachain/protocol-contracts/contracts/zevm/libraries/index.tsis excluded by!typechain-types/**typechain-types/contracts/testing/mock/ZRC20Mock.sol/IZRC20Mock.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/Errors.sol/INotSupportedMethods__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/Revert.sol/Revertable__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/evm/ERC20Custody__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/evm/GatewayEVM__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorBase__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorNative__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/evm/ZetaConnectorNonNative__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistryErrors__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistryEvents__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/IBaseRegistry__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/interfaces/IBaseRegistry.sol/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/helpers/interfaces/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/GatewayZEVM__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/SystemContract.sol/SystemContract__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/ZRC20.sol/ZRC20__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/ICoreRegistry__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/IGatewayZEVM.sol/IGatewayZEVMErrors__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/IGatewayZEVM.sol/IGatewayZEVM__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/IZRC20.sol/IZRC20Metadata__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/IZRC20.sol/IZRC20__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/UniversalContract.sol/UniversalContract__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/interfaces/index.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/libraries/GatewayZEVMValidations__factory.tsis excluded by!typechain-types/**typechain-types/factories/@zetachain/protocol-contracts/contracts/zevm/libraries/index.tsis excluded by!typechain-types/**typechain-types/factories/contracts/OnlySystem__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/EVMSetup.t.sol/EVMSetup__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/FoundrySetup.t.sol/FoundrySetup__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/TokenSetup.t.sol/TokenSetup__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/ZetaSetup.t.sol/ZetaSetup__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/mock/ZRC20Mock.sol/IZRC20Mock__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/mock/ZRC20Mock.sol/ZRC20Mock__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/mockGateway/NodeLogicMock__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/mockGateway/WrapGatewayEVM__factory.tsis excluded by!typechain-types/**typechain-types/factories/contracts/testing/mockGateway/WrapGatewayZEVM__factory.tsis excluded by!typechain-types/**typechain-types/hardhat.d.tsis excluded by!typechain-types/**typechain-types/index.tsis excluded by!typechain-types/**yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (8)
package.json(1 hunks)packages/commands/src/query/contracts/index.ts(1 hunks)packages/commands/src/query/contracts/list.ts(1 hunks)packages/commands/src/query/contracts/show.ts(1 hunks)packages/commands/src/query/index.ts(2 hunks)src/constants/addresses.ts(1 hunks)src/schemas/commands/contracts.ts(1 hunks)utils/addressResolver.ts(1 hunks)
🧠 Learnings (5)
📓 Common learnings
Learnt from: hernan-clich
PR: zeta-chain/toolkit#238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: zeta-chain/toolkit#332
File: packages/commands/src/bitcoin/inscription/call.ts:66-67
Timestamp: 2025-05-27T16:09:13.029Z
Learning: The ZetaChain toolkit uses comprehensive zod schema validation for command inputs, including hexStringSchema for hex string validation with regex /^(0x)?[0-9a-fA-F]*$/, so manual validation in the command logic is typically unnecessary as validation occurs during option parsing.
Learnt from: hernan-clich
PR: zeta-chain/toolkit#329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like `baseEvmDepositOptionsSchema` are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/depositAndCall.ts:0-0
Timestamp: 2025-06-13T15:33:54.781Z
Learning: fadeev prefers responses in English.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/deposit.ts:0-0
Timestamp: 2025-06-13T15:32:09.225Z
Learning: User fadeev prefers that responses be in English; avoid replying in Russian in future interactions.
package.json (3)
Learnt from: s2imonovic
PR: #370
File: contracts/UniswapV3SetupLib.sol:124-128
Timestamp: 2025-06-26T14:06:16.147Z
Learning: In the ZetaChain toolkit codebase, accurate documentation is important - comments should correctly reflect what the code actually does (e.g., fixing comments that incorrectly reference Uniswap V2 when the code deploys V3 contracts).
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: #291
File: packages/commands/src/accounts/list.ts:0-0
Timestamp: 2025-04-17T15:59:39.612Z
Learning: In the zetachain/toolkit repository, file system operations should use the safe helper functions from fsUtils.ts (like safeReadFile, safeReadDir, safeExists) instead of direct Node.js fs methods to ensure consistent error handling.
packages/commands/src/query/contracts/index.ts (1)
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
src/schemas/commands/contracts.ts (4)
Learnt from: hernan-clich
PR: #329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like baseEvmDepositOptionsSchema are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: #332
File: packages/commands/src/bitcoin/inscription/call.ts:66-67
Timestamp: 2025-05-27T16:09:13.029Z
Learning: The ZetaChain toolkit uses comprehensive zod schema validation for command inputs, including hexStringSchema for hex string validation with regex /^(0x)?[0-9a-fA-F]*$/, so manual validation in the command logic is typically unnecessary as validation occurs during option parsing.
Learnt from: hernan-clich
PR: #329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, mutual exclusivity between 'name' and 'privateKey' is implemented using the 'namePkRefineRule' in the individual command schemas that extend the base schema, rather than in the base schema itself. This design pattern allows the base schema to remain flexible while specific commands can apply constraints as needed.
packages/commands/src/query/contracts/list.ts (1)
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
🧬 Code Graph Analysis (5)
packages/commands/src/query/contracts/index.ts (2)
packages/commands/src/query/contracts/list.ts (1)
listCommand(103-118)packages/commands/src/query/contracts/show.ts (1)
showCommand(66-81)
packages/commands/src/query/index.ts (1)
packages/commands/src/query/contracts/index.ts (1)
contractsCommand(6-11)
packages/commands/src/query/contracts/show.ts (4)
src/schemas/commands/contracts.ts (1)
contractsShowOptionsSchema(11-16)packages/commands/src/query/contracts/list.ts (1)
fetchContracts(22-35)utils/addressResolver.ts (1)
formatAddress(308-322)src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
src/schemas/commands/contracts.ts (1)
src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
packages/commands/src/query/contracts/list.ts (4)
src/schemas/commands/contracts.ts (1)
contractsListOptionsSchema(5-9)src/constants/addresses.ts (1)
CONTRACT_REGISTRY_ADDRESS(2-3)utils/addressResolver.ts (1)
formatAddress(308-322)src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: hernan-clich
PR: zeta-chain/toolkit#238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: zeta-chain/toolkit#332
File: packages/commands/src/bitcoin/inscription/call.ts:66-67
Timestamp: 2025-05-27T16:09:13.029Z
Learning: The ZetaChain toolkit uses comprehensive zod schema validation for command inputs, including hexStringSchema for hex string validation with regex /^(0x)?[0-9a-fA-F]*$/, so manual validation in the command logic is typically unnecessary as validation occurs during option parsing.
Learnt from: hernan-clich
PR: zeta-chain/toolkit#329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like `baseEvmDepositOptionsSchema` are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/depositAndCall.ts:0-0
Timestamp: 2025-06-13T15:33:54.781Z
Learning: fadeev prefers responses in English.
Learnt from: fadeev
PR: zeta-chain/toolkit#346
File: packages/commands/src/ton/deposit.ts:0-0
Timestamp: 2025-06-13T15:32:09.225Z
Learning: User fadeev prefers that responses be in English; avoid replying in Russian in future interactions.
package.json (3)
Learnt from: s2imonovic
PR: #370
File: contracts/UniswapV3SetupLib.sol:124-128
Timestamp: 2025-06-26T14:06:16.147Z
Learning: In the ZetaChain toolkit codebase, accurate documentation is important - comments should correctly reflect what the code actually does (e.g., fixing comments that incorrectly reference Uniswap V2 when the code deploys V3 contracts).
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: #291
File: packages/commands/src/accounts/list.ts:0-0
Timestamp: 2025-04-17T15:59:39.612Z
Learning: In the zetachain/toolkit repository, file system operations should use the safe helper functions from fsUtils.ts (like safeReadFile, safeReadDir, safeExists) instead of direct Node.js fs methods to ensure consistent error handling.
packages/commands/src/query/contracts/index.ts (1)
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
src/schemas/commands/contracts.ts (4)
Learnt from: hernan-clich
PR: #329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, base schemas like baseEvmDepositOptionsSchema are intentionally kept flexible, with mutual exclusivity refinements like name/privateKey validation happening in the specific command implementations that extend the base schema, rather than in the base schema itself.
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
Learnt from: hernan-clich
PR: #332
File: packages/commands/src/bitcoin/inscription/call.ts:66-67
Timestamp: 2025-05-27T16:09:13.029Z
Learning: The ZetaChain toolkit uses comprehensive zod schema validation for command inputs, including hexStringSchema for hex string validation with regex /^(0x)?[0-9a-fA-F]*$/, so manual validation in the command logic is typically unnecessary as validation occurs during option parsing.
Learnt from: hernan-clich
PR: #329
File: utils/evm.command.helpers.ts:21-38
Timestamp: 2025-05-16T20:59:05.735Z
Learning: In the ZetaChain toolkit, mutual exclusivity between 'name' and 'privateKey' is implemented using the 'namePkRefineRule' in the individual command schemas that extend the base schema, rather than in the base schema itself. This design pattern allows the base schema to remain flexible while specific commands can apply constraints as needed.
packages/commands/src/query/contracts/list.ts (1)
Learnt from: hernan-clich
PR: #238
File: packages/tasks/src/verify.ts:0-0
Timestamp: 2025-03-18T14:06:01.531Z
Learning: The verify.ts file in the zeta-chain/toolkit repository already implements proper validation for empty contract lists using a condition that checks names.length.
🧬 Code Graph Analysis (5)
packages/commands/src/query/contracts/index.ts (2)
packages/commands/src/query/contracts/list.ts (1)
listCommand(103-118)packages/commands/src/query/contracts/show.ts (1)
showCommand(66-81)
packages/commands/src/query/index.ts (1)
packages/commands/src/query/contracts/index.ts (1)
contractsCommand(6-11)
packages/commands/src/query/contracts/show.ts (4)
src/schemas/commands/contracts.ts (1)
contractsShowOptionsSchema(11-16)packages/commands/src/query/contracts/list.ts (1)
fetchContracts(22-35)utils/addressResolver.ts (1)
formatAddress(308-322)src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
src/schemas/commands/contracts.ts (1)
src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
packages/commands/src/query/contracts/list.ts (4)
src/schemas/commands/contracts.ts (1)
contractsListOptionsSchema(5-9)src/constants/addresses.ts (1)
CONTRACT_REGISTRY_ADDRESS(2-3)utils/addressResolver.ts (1)
formatAddress(308-322)src/constants/api.ts (1)
DEFAULT_EVM_RPC_URL(3-4)
🔇 Additional comments (15)
src/constants/addresses.ts (1)
2-3: Verify mainnet CONTRACT_REGISTRY_ADDRESSPlease confirm that the hard-coded address
0x7cce3eb018bf23e1fe2a32692f2c77592d110394in your constants file is the official mainnet Registry contract and not a testnet deployment. You can cross-check it on Etherscan or against your deployment records. If you need to support multiple networks, consider making this address network-configurable or adding an inline comment/documentation link.• File:
src/constants/addresses.ts(lines 2–3)
• Usage: imported inpackages/commands/src/query/contracts/list.tspackages/commands/src/query/index.ts (2)
5-5: LGTM!The import follows the established pattern and maintains alphabetical ordering.
14-14: LGTM!The command integration follows the existing pattern and maintains alphabetical ordering within the command hierarchy.
packages/commands/src/query/contracts/index.ts (1)
1-11: LGTM!The command group implementation follows commander.js best practices with appropriate aliasing, clear description, and proper subcommand integration. The structure is consistent with the existing codebase patterns.
packages/commands/src/query/contracts/show.ts (3)
19-33: LGTM!The
findContractByChainIdfunction is well-implemented with proper filtering logic and case-insensitive type matching, which improves user experience.
45-57: Excellent user experience with helpful error messages.The error handling provides clear feedback with the specific chain ID and type that wasn't found, plus a helpful list of available contracts. This makes debugging much easier for users.
78-80: LGTM!The command action properly validates options using zod schema before execution, which aligns with the established patterns in the ZetaChain toolkit codebase.
src/schemas/commands/contracts.ts (1)
11-16: Schema definition looks good.The validation schema correctly defines required fields (
chainId,type) and provides appropriate defaults for optional fields (json,rpc).utils/addressResolver.ts (2)
281-302: Well-implemented address parsing function.The function correctly handles both direct EVM addresses and left-padded bytes32 values. The use of
ethers.isAddressfor validation andethers.getAddressfor checksumming follows best practices.
304-322: Robust address formatting with appropriate fallbacks.The function provides a good fallback strategy: EVM address parsing first, then UTF-8 decoding with null byte cleanup, and finally returning the original hex string if all else fails.
packages/commands/src/query/contracts/list.ts (5)
1-21: Good setup with proper imports and type definitions.The imports are appropriate and the
ContractDatainterface correctly represents the contract registry structure. Type inference from the schema provides good type safety.
22-35: Clean and correct contract fetching implementation.The function properly sets up the ethers provider and contract instance, with appropriate error handling delegated to the calling function.
37-57: Correct table formatting with conditional columns.The function properly builds table headers and rows based on the selected columns. The use of
formatAddressfor address display ensures consistent formatting.
59-101: Robust main function with comprehensive error handling.The function handles all scenarios well: spinner management for non-JSON output, proper sorting, multiple output formats, empty results, and comprehensive error handling.
103-118: Well-structured command definition.The command follows best practices with proper aliases, clear description, and good option definitions. The schema validation ensures type safety. Note: This relates to the earlier flagged inconsistency with the schema's columns default.
|
Might need to hold off on merging this until protocol contracts v13.1.0 stable is released. |
Contract addresses fresh from the registry 🥬
LIst
Show
How a ninja would use this command:
Summary by CodeRabbit